This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: untarring symlinks with ../ fails randomly, silghtly OT


On Jul  4 16:20, Corinna Vinschen wrote:
> On Jul  4 08:21, Ryan Johnson wrote:
> > However, I was wrong about not seeing the problem since. Choosing a
> > random source dir to blow away:
> > >$ rm -rf Python-2.6.6
> > >rm: cannot remove `Python-2.6.6/Lib/lib2to3/tests': Directory not empty
> > >$ rm -rf Python-2.6.6
> > >$
> > 
> > This seems to happen more than half the time (different non-empty
> > dir every time). Naturally, running under strace makes the problem
> > go away (it doesn't help that strace kills stderr, where any error
> > messages might have gone).
> > 
> > Running the following command 10x:
> > 
> > $ tar -xaf Python-2.6.6.tar.bz2 && sleep 3 && (rm -rf Python-2.6.6
> > || (echo 'Retrying...' && rm -rf Python-2.6.6))
> > 
> > I get six times with no error, two times with one error, one time
> > each with two and three errors.
> 
> I tried this(*) with Cygwin 1.7.9 as well as with the latest from CVS
> on 2K8R2 and it just works.  In a VM.

Btw., I would like to stress again that Cygwin does *not* lock files
it opens, except in very rare circumstances.  It always opens files
with all sharing flags set, except in these scenarios:

1. @file handling, file is opened w/ FILE_SHARE_READ only.

2. rename(): Omit FILE_SHARE_DELETE flag on Samba to avoid
   STATUS_ACCESS_DENIED if file has the DOS R/O attribute set.

3. unlink(): Tries to open with FILE_SHARE_DELETE only to check for
   files-in-use.  If that works, the file is deleted anyway.  If not,
   it retries to open with all sharing flags set.

4. On exit, if a DLL can't be found, the executable is opened without
   FILE_SHARE_DELETE to scan for DLLs.

5. When exec'ing a file, it's potentially tested for being a script.
   If so, the FILE_SHARE_DELETE is omitted.

I'm going to change 1, 4, and 5, but they can't be the culprit for what
you see.

If a file can't be removed, it's typically a non-Cygwin process holding
a handle to the file with file sharing set to 0.  Consider that a Cygwin
process opens the file with all sharing flags set, so removing the file
will at least work by moving it to the trashcan.  Well, except on remote
drives, that is, because we don't even know if a trashcan is available
on the remote drive and even if so, most of the time it's not accessible
from remote.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]