#185 Temp directory suddenly erased

open
nobody
None
5
2004-10-12
2004-10-12
No

I'm running ed2k-gtk-gui 0.6.3 with hybrid core version
1002. I had a large queue of downloads, but suddenly I
started seeing the following errors again and again in
the status window:

"Couldn't create Temp File No such file or directory"

and:

ERROR: partial info not saved: <files>

Looking into the ~/.eDonkey/temp dir, it seems that all
but 3 of the items I had queued had been deleted!
Everything in the "incoming" directory remained, however.

At the time, I had over 90GBs of free space, so that is
not the issue.

The gui_statuslog doesn't seem to show any other
relevant information.

Discussion

  • Andrew Martin

    Andrew Martin - 2004-10-12

    Logged In: YES
    user_id=646174

    This may be related to bug #1028017. The reason that bug
    submitter "lost" his list of downloads was probably because
    his temp dirs were erased.

     
  • Tim-Philipp Muller

    Logged In: YES
    user_id=583691

    The reason for this is that the number of max. allowed open file descriptors for
    your user is not large enough.

    See the ed2k-gtk-gui handbook:

    http://ed2k-gtk-gui.sourceforge.net/docs/en-5.html#ss5.20

    You will also find advice there on how to increase that limit and make sure it
    doesn't happen again.

    I am a bit shocked though that any items had been deleted? That shouldn't have
    happened.

    * How many items are you talking about? (Files you mean, right?)
    * Are there any *.bak files left anywhere in the temp folder?
    * Are there any *.met files left anywhere in the temp folder?
    * Are there any *.part files left anywhere in the temp folder?
    * Have the sub-directories in temp for each download also been deleted?

    #1028017 usually happens after running out of disk space or a system crash,
    then the .met file isn't written, and the core doesn't pick up the partial downloads
    on restart. It's usually fixed by either renaming x.part.met.bak to x.part.met and
    restarting the core, or via MetFileRegenerator. I don't think #1028017 is relevant
    to your problem, as those error messages are quite hard to miss).

    Cheers
    -Tim

     
  • Andrew Martin

    Andrew Martin - 2004-10-12

    Logged In: YES
    user_id=646174

    Thanks for pointing me to that part of the handbook.
    'ulimit -n' now reports 4096 after re-logging into X. I did
    not restart the core, however. Is that necessary for it to
    use the new limit?

    In answer to your questions, I had about 20 or 30 items
    queued for download. So while I'm not sure exactly how many
    "part" files existed at the time, I'm sure it was in the
    hundreds.

    The entire subdir in temp was erased, not just the files
    inside of it. Only three subdirs remained untouched.
    Everything else was wiped out completely.

    I'm using Linux kernel 2.6.9-rc3 if that's in any way relevant.

     

Log in to post a comment.