[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Pan-users] Re: slrn and pan living together in harmony?

From: Duncan
Subject: [Pan-users] Re: slrn and pan living together in harmony?
Date: Mon, 21 May 2007 17:07:54 +0000 (UTC)
User-agent: Pan/0.129 (Benson & Hedges Moscow Gold)

Matej Cepl <address@hidden> posted
address@hidden, excerpted below, on  Mon, 21 May
2007 17:47:59 +0200:

> On 2007-05-10, 14:16 GMT, Duncan wrote:
>> It should be possible.  Charles has designed pan with that in mind, and
>> pan uses compatible newsrc and scorefile formats. However, I've not
>> tried it so I don't know the details at least on the slrn side.
> OK, just to confirm that is doesn't work -- tried second time now, and
> when changed servers.xml to this (I have a local leafnode):
> <?xml version="1.0" encoding="utf-8" ?> <server-properties>
>   <server id="1">
>     <host>localhost</host>
>     <port>119</port>
>     <username></username>
>     <password></password>
>     <expire-articles-n-days-old>31</expire-articles-n-days-old>
>     <connection-limit>1</connection-limit>
>     <newsrc>/home/matej/.newsrc</newsrc>
>     <rank>1</rank>
>   </server>
> </server-properties>

I'd suggest you use symlinks instead, or tell slrn to use the default pan 
one if it can be so configured.  It hadn't occurred to me to try to 
change the pan config in that manner, but it's possible that's why it's 

> On the first run when running pan (pan-0.129-1.fc6) it had correctly
> subscribed the same newsgroups as slrn, but with some read articles.
> However, after sthudown of pan, the .newsrc is busted -- neither slrn
> nor pan (after recovery of the old .newsrc from backup and trying again)
> see any NG subscribed.
> I tried running it with strace and the result was strange -- when
> running grep newsrc on both first and the second run of pan, I got a
> slight difference:
> address@hidden tmp]$ grep newsrc pan.strace 14579
> access("/home/matej/.newsrc", F_OK) = 0 14579
> open("/home/matej/.newsrc", O_RDONLY) = 6 14579
> open("/home/matej/.newsrc.tmp", O_WRONLY|O_CREAT|O_TRUNC,\
>     0666) = 6
> 14579 unlink("/home/matej/.newsrc")     = 0 14579
> rename("/home/matej/.newsrc.tmp", "/home/matej/.newsrc") \
>     = 0
> 14579 chmod("/home/matej/.newsrc", 0600) = 0 address@hidden tmp]$ grep
> newsrc pan.strace2 14586 access("/home/matej/.newsrc", F_OK) = 0 14586
> open("/home/matej/.newsrc", O_RDONLY) = 6 14586
> open("/home/matej/.newsrc.tmp", O_WRONLY|O_CREAT|O_TRUNC,\
>     0666) = 7
> 14586 unlink("/home/matej/.newsrc")     = 0 14586
> rename("/home/matej/.newsrc.tmp", "/home/matej/.newsrc") \
>     = 0
> 14586 chmod("/home/matej/.newsrc", 0600) = 0 14586
> open("/home/matej/.newsrc.tmp", O_WRONLY|O_CREAT|O_TRUNC,\
>     0666) = 6
> 14586 unlink("/home/matej/.newsrc")     = 0 14586
> rename("/home/matej/.newsrc.tmp", "/home/matej/.newsrc") \
>     = 0
> 14586 chmod("/home/matej/.newsrc", 0600) = 0 address@hidden tmp]$
> No idea, what's the difference between 6 and 7 as a return value of
> open("/home/matej/.newsrc.tmp", O_WRONLY|O_CREAT|O_TRUNC,0666) system
> call.

OK, your grep-only and question about the return code betray the same 
lack of familiarity with strace.  "open" calls return a file descriptor, 
where the number indicates that it's the Nth file open at the same time 
by that app.  (Note that STDIN, STDOUT, and STDERR normally take file 
descriptors too.)  Further references to the file (the actual read, scan-
position, or write) while it is open refer not to the name, but to the 
file descriptor returned by the open call.  Thus with grep as you used 
it, you see all the opens, and other misc. actions (stat, rename, unlink, 
etc) done on the closed file, but you don't see what the application did 
with the file once it opened it.  Of course, note that a file may be 
opened and closed repeatedly, and if the number of open files is 
different, the result of subsequent open calls will also be different.

Thus, the difference in the results simply indicates the number of other 
open files.  You'll need to scan the strace for other activity on the 
file descriptor returned by open in ordered to see what pan is actually 
doing with the file while it's open.

Also, you didn't say and all you show is the grep, not the strace, so I 
can't see what your strace command was.  To avoid /some/ of the noise, 
you can use the -efile switch, so strace only reports on file activity.  
Of course, you'll still have all the other files activity, including all 
the libraries and fonts and etc, and libraries are often checked for in 
several places before the right one is found, so it can still be a LOT of 
noise, but at least you don't have the non-file activity to worry about 
as well.  You can then use grep reporting line numbers or the like, to 
find the line numbers to start looking at, then follow thru until that 
file descriptor is closed, before going on to the next time the file is 

(When all you are looking for is where the app looks for its config files 
or something, you can narrow that further, to -eopen or similar, thus 
avoiding stats and renames and scans and reads of open files, and file 
closes, etc, and use grep on that, since it's only the opens you are 
looking for.  However, here you may be interested in what pan is actually 
doing with the file, so -eopen isn't all that useful, nor is grepping on 
the filename alone.)

Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

reply via email to

[Prev in Thread] Current Thread [Next in Thread]