[xilolee]

When Emule Recovers A Corrupted File And thus The .part.met File Is Succesfully Recovered, it is set to read-only state (in its properties - attributes).
When the file will be completed, the hashing will be blocked:

Quote

10/02/2013 10.39.38: File in Hashing: "bla bla bla.BLA" "C:\Program Files (x86)\eMule\100.part.met"
10/02/2013 10.39.38: Impossibile aprire (Unable to open) C:\Program Files (x86)\eMule\100.part.met () - No such file or directory

The work-around = temporary solution is to remove the read-only attribute from the .part.met file and restart emule (because every other options on the file are greyed: no stop, no resume), and the file will be hashed and completed.

EDIT: Windows 8 and temp folder inside emule installation folder (I obviously allowed eMule to write in emule folders and subfolders)


This could happen when safe .met/.dat file writing is not set to always (i.e., when it is set to always, there are no problems!).

This post has been edited by xilolee: 12 February 2013 - 10:09 PM

[ducho]

So another workaround is to set safe .met/.dat file writing to always.

A bit off-topic, why one should use "Never" or "on shutdown" for safe .met/.dat file writing ?

[xilolee]

Because:

Quote

Safe .met / .dat file writing
On newer operating systems using NTFS as file system there is usually no need to change this option. If downloads are reproducibly lost on crashes or eMule shut downs the safer method should be tried.
Depending on the hardware used, this option may notably increase disk activity / system load or prolong eMule's shut down!

And: Possible Bug? Delayed Connection To A Server When Safe .met/.dat File Writing Is Set To Always (click)