Re: [Mldonkey-users] File corruption following, mldonkey hardening proposal

[Markus Hitter]

Am Sonntag, 18.05.03 um 17:02 Uhr schrieb Lionel Bouton:

> > If you set incoming/ and all files therein to read-only, does this 
> > trigger anything? mlnet should work as before, IMO.
>
> Hum, I don't want to take this risk, I've no idea what will happen if 
> the dir is read-only when I'll commit one file.

At worst, the file is lost. But how about making a copy before?

I suggest this because it could help to track down the fault: is mlnet 
actually creating a new file or appears the file again because mlnet 
still reads from it. On most file systems, you can read from a already 
deleted file if you got a pointer to it before deletion. Using this 
possibility is risky at best ;-)

In general, it's not a good idea to move around files which an app 
accesses at this moment. This is why I quit mlnet before doing such 
things at the shell level. Software can't do much against other 
software "stealing" their files. There's a mechanism called file 
locking, but I don't know wether mlnet uses it. Not all file systems 
support it.

If you don't want to stop mlnet, check the file in the temp dir without 
altering it and commit it via mlnet when done. If this still gives bad 
files, you've detected a bug.


Have fun,
Markus