libs/newlib-cygwin
libs/newlib-cygwin
4
0
Fork 0
mirror of git://sourceware.org/git/newlib-cygwin.git synced 2025-02-18 15:09:32 +08:00
Code Issues Projects Releases Wiki Activity

* syscalls.cc (unlink): Don't use "delete on close" on remote shares.

Browse Source
This commit is contained in:
Corinna Vinschen 2004-09-17 09:10:53 +00:00
parent 95a12a8594
commit af444ab7be
2 changed files with 22 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
winsup/cygwin/ChangeLog
View File

@ -1,3 +1,7 @@
2004-09-17 Corinna Vinschen <corinna@vinschen.de>
* syscalls.cc (unlink): Don't use "delete on close" on remote shares.
2004-09-17 Corinna Vinschen <corinna@vinschen.de>
* cygwin.din (_impure_ptr): And export again. There are libs out there.

20
winsup/cygwin/syscalls.cc
View File

@ -175,8 +175,24 @@ unlink (const char *ourname)
| FILE_ATTRIBUTE_SYSTEM));
}
/* Attempt to use "delete on close" semantics to handle removing
a file which may be open. */
if (wincap.has_delete_on_close ())
a file which may be open.
CV 2004-09-17: Not if the file is on a remote share. If two processes
have open handles on a file and one of them calls unlink, then it
happens that the file is remove from the remote share even though the
other process still has an open handle. This other process than gets
Win32 error 59, ERROR_UNEXP_NET_ERR when trying to access the file.
For some reason, that does not happen when using DeleteFile, which
nicely succeeds but still, the file is available for the other process.
To reproduce, mount /tmp on a remote share and call
bash -c "cat << EOF"
Microsoft KB 837665 describes this problem as a bug in 2K3, but I have
reproduced it on shares on Samba 2.2.8, Samba 3.0.2, NT4SP6, XP64SP1 and
2K3 and in all cases, DeleteFile works, "delete on close" does not. */
if (!win32_name.isremote () && wincap.has_delete_on_close ())
{
HANDLE h;
h = CreateFile (win32_name, 0, FILE_SHARE_READ, &sec_none_nih,