#32 par recovery goes too far...

[Frederick Bruckman]

At the PAR checking phase, "nget" apparently tries to
fulfill every PAR file that's found in the download
directory, without regard to whether it matches the
command line filters or not. It mainly only leads to
extra error messages, but when the download directory
is cluttered, it adds a lot of extra time to the par
checking phase.

[Matthew Mueller]

Logged In: YES
user_id=65253

The idea behind that was that even if the post of the
matching par file may have expired from the server, if the
user ran the nget command again they should still get the
same error. The PAR handling was written on the assumption
of using different download directories for each thing. I
can see how this is not good for shared download dirs. I
can't really think of any good way to handle this other than
just adding Yet Another Option for if nget should only check
par files that are matched.

[Frederick Bruckman]

Logged In: YES
user_id=803104

I'm thinking if "nget" is asked to download "-r foo.*", we
should only care about par files in the download directory
that match "foo.*". How about if the subject regexp filter
were applied to the directory listing? That way, par files
that have rolled off the server (that are in the directory)
would still be used, but (most) unrelated par files would
not. There'd have to be a fallback plan if nothing matches,
in case folks were matching on something in the subject
besides the file name.

I know I could put each download in a separate directory,
it's just inconvenient to do that. I run several instances
of "nget" in "screen" virtual terminals, one fetching the
group lists, one viewing the article list, others
downloading articles..., another to do "unrar" and such. If
I start the screen in the common download directory, each
new shell starts in the same directory, which is nice. For
instance, running the listing in one shell marks the files
already downloaded (in progress) in the other, eventually
just listing the files that still need to be downloaded. If
I use temporary directories, I have to always "cd" in each
shell, which gets confusing, and if I delete the directory
that the screen started in, new shells don't have a CWD. So
there's my plea. :-)