Matej Cepl <[EMAIL PROTECTED]> posted
[EMAIL PROTECTED], 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
failing.
> 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:
>
> [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
opened.
(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
_______________________________________________
Pan-users mailing list
Pan-users@nongnu.org
http://lists.nongnu.org/mailman/listinfo/pan-users
