pan-users
[Top][All Lists]
Advanced

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

Re: [Pan-users] Re: 'hundreds' of strange extracted file when downloadin


From: wim . delvaux
Subject: Re: [Pan-users] Re: 'hundreds' of strange extracted file when downloadingmultipart messages
Date: Thu, 24 Apr 2008 23:51:55 +0200
User-agent: KMail/1.9.6 (enterprise 0.20070907.709405)

On Thursday 24 April 2008 23:33:44 address@hidden wrote:
> Thanx for the explanation.
>
> Where did I 'accidently' ask to save the 'text' messages too ?

Never mind, I found it  

Thx

W
>
> Thx
>
> W
>
> On Thursday 24 April 2008 18:01:25 Duncan wrote:
> > Travis <address@hidden> posted
> > address@hidden, excerpted below, on  Thu, 24
> >
> > Apr 2008 06:57:44 -0700:
> > > ----- Original Message -----
> > >
> > >> I run pan version 0.132.
> > >>
> > >> When I download a multipart message from news.usenetserver.com I get a
> > >> lot of files with names like :
> > >>
> > >> M8WPj.14920$HY2.13951-epkf52SaZeZP2roSf1MJ43itZ/
> > >> address@hidden
> > >>
> > >> I got other extension too (so not only with usenetserver.com.msg).
> > >
> > > You have Pan set to save "text" as well as the attachments.
> >
> > Travis is correct, depending on where you are looking, but here's a
> > somewhat more detailed explanation.
> >
> > Pan saves messages using the (sanitized to filesystem safe) Message-ID,
> > which according to the RFCs should be globally unique -- there should
> > never be two different messages anywhere in the world at any time with
> > the same Message-ID.
> >
> > Different news clients (and original posting servers, if the news client
> > doesn't supply its own) use different algorithms to come up with the
> > Message-ID, however.  Many use some form of a combination of from address
> > (either the poster's, or the posting server's) to hopefully keep
> > collisions in "space" from occurring, timestamp, to keep collisions in
> > time from occurring, and random number, just in case, but it's up to the
> > implementation exactly what they use, as long as it's unique.
> >
> > That's why the message files appear to have such strange names -- they
> > are based on the Message-ID, which isn't standardized except in the
> > characters it may contain and that it must be unique, and isn't really
> > designed for file-naming, the use to which pan puts it.  Pan uses the
> > Message-ID as a filename, however, in ordered to help keep things
> > straight, since it's unique to the message and pan is designed to be able
> > to track and know when it has already downloaded the same message across
> > multiple servers.  (The other form of message numbering, normally
> > sequential by group, is server-specific, and therefore won't help
> > tracking messages between servers.)
> >
> > All that said, normally, the only place these filenames appear is in
> > pan's cache, which by default is pretty small, 10 MB. (The cache can be
> > set larger manually, by editing preferences.xml in pan's settings dir
> > directly. I run a multi-gigabyte cache, save to cache, and then sort and
> > save off messages from there after they are all stored in local cache.)
> > Since pan handles its cache automatically, you'll not normally see these
> > files unless you go manually trawling thru the cache.
> >
> > However, if as Travis suggested, if you tell pan to save the text message
> > itself, not just attachments, it'll save this more or less raw text
> > message.  This is nice if you want to save a text message, tho you may
> > want to rename it to something more appropriate (say the subject)
> > afterward.  I do this from time to time.  It's also useful on "broken"
> > attachments that pan can't properly save on its own, however, as it may
> > be possible to recover the attachment using other tools designed to deal
> > for the purpose.  I do this too, occasionally.
> >
> > So basically, if you are telling pan to save the text message not just
> > the attachments, you'll get these wherever you have pan saving its
> > messages.  Tell it to save attachments only, and you'll not have to worry
> > about them.  Or, if you are examining pan's cache, don't worry about it,
> > as pan should manage them on its own unless you've deliberately set it up
> > to handle manually, as I have.
>
> _______________________________________________
> Pan-users mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/pan-users






reply via email to

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