Am 12.10.2009 16:26, Alan Bateman schrieb:
Ulf Zibis wrote:
Am 12.10.2009 15:03, Ulf Zibis schrieb:
Additionally something like Path#unlock() would be helpful, if
copy/delete fails. For example see:
http://diamondcs.com.au/freeutilities/fileunlocker.php
Additionally see: http://ccollomb.free.fr/unlocker/
I assume this type of thing can lead to data loss and/or hard to
diagnose corruption.
Of course, such method should be used with care. The developer/user
should first retrieve/examine some information like the blocking process
from the locked file. But this option should be more comfortable, than
rebooting the hole system, which too could have data loss/corruption in
consequence.
... and delete always has data loss in effect. ;-)
If you are running into sharing violations then try out the file
system API as the Windows provider opens files by default to allow
delete access (ie: close to Unix semantics by default with provider
specific options to control the DOS sharing mode if you really want).
In java.nio.file.Filesystem b72 I don't find information about sharing
attributes.
The only case where we still have a problem is memory-mapped files.
Changing the long standing behavior of the java.io classes is another
matter as that would likely break existing applications that rely on
the current/long standing behavior.
-Alan.
-Ulf
