Mail Archives: cygwin/2010/12/12/11:55:31
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
- Raw text -