#32 par recovery goes too far...

open
None
5
2004-12-09
2004-11-15
No

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.

Discussion

  • Matthew Mueller

    Matthew Mueller - 2004-12-09
    • assigned_to: nobody --> donut
     
  • Matthew Mueller

    Matthew Mueller - 2004-12-09

    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. :-)

     

Log in to post a comment.