Am 12.12.2010 16:46, schrieb Corinna Vinschen: > On Dec 12 16:19, Corinna Vinschen wrote: >> On Dec 12 16:14, Matthias Andree wrote: >> > Am 12.12.2010 16:12, schrieb Corinna Vinschen: >> > > On Dec 12 15:16, Matthias Andree wrote: >> > >> Am 12.12.2010 13:42, schrieb Corinna Vinschen: >> > >> >> > >> > So, what cygwin tries to do in the first place is to move files in use >> > >> > into the recycle bin. However, on Windows you need DELETE access >> > >> > rights >> > >> > to be able to do so. And, this doesn't work for remote drives. On >> > >> > remote drives we can only try to rename the file to some temporary >> > >> > filename and hope for the best. Afterwards Cygwin sets the delete >> > >> > dispostion flag and returns success if setting the dispostion flag >> > >> > succeeded. After all, that's the maximum possible on Windows, and for >> > >> > all we can tell the file has been deleted. The fact that the >> > >> > directory >> > >> > entry lingers until the last handle to the file has been closed is >> > >> > something Cygwin has no control over. >> > >> >> > >> Well, there's the problem. >> > > >> > > No, it's not, at least not on local drives. Read again. Files and >> > > directories in use are moved into the bin. If that fails, unlink/rmdir >> > > fails. >> > >> > Then I wonder what makes my cygport (or the rm command it uses) fail as it >> > removes the workdir... >> >> I guess debugging would sched a light... > > Something else occured to me. I guess I'm too much used to run the > current snapshots, rather than the current release version of Cygwin. > > Probably the file-in-use stuff is not really your problem. There's > another problem which is this: If the directory you want to remove is > the CWD of a Windows process, then removing the dir fails. The reason > is that the CWD handle of a Windows process is opened without the > FILE_SHARE_DELETE sahring mode set. So, any try to rename or remove > that dir will fail. > > For Cygwin 1.7.7, this is also true for Cygwin processes. There was > that handle problem with Cygwin's CWD handling on Vista and later which > has been discussed on this list between August and October. Since we > had no way to fix this problem at this point, Cygwin 1.7.7 reverted to > the old Cygwin 1.5 behaviour to use the Win32 function SetCurrentDirectory > to set the CWD. With obvious results. > > In the meantime John Carey was so kind to dive into the OS and found a > solution to replicate Vista's CWD handling so that Cygwin 1.7.8 will > again be able to remove directories which are the CWD of any Cygwin > process. The problem with native, non-Cygwin processes holding a > CWD handle to this directory will of course persist.
Ah, that might possibly account for races, depending on how fast we leave the directory alone in 1.7.7. > So, here's the question: Did you try a recent Cygwin snapshot from > http://cygwin.com/snapshots/? Perhaps it fixes your problem. Not yet, but can do. Does that entail reinstalling cyglsa since 1.7.7 (just planning to keep the number of reboots down :-))? -- Matthias Andree -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
