untarring symlinks with ../ fails randomly, silghtly OT
Mon Jul 4 12:00:00 GMT 2011
On Mon, 2011-07-04 at 12:46 +0200, Corinna Vinschen wrote:
> On Jul 4 11:15, Wolf Geldmacher wrote:
> > As an aside:
> > I also used to have some trouble with "rm -rf" of a directory
> > hierarchy failing more or less reproducibly (like: 80% of the
> > time) because files were presumably still "in use". Repeating
> > the command several times would succeed, though.
> > Downgrading from cygwin1.dll/188.8.131.52 to cygwin1.dll/184.108.40.206
> > seems to have solved that issue as well - still have to see
> > the first "retry to delete".
> > This may or may not be related to the original report, as it also reeks
> > of a race condition during file/directory operations.
> I can neither reproduce the tar problem, nor can I reprocude the rm
> problem. I tried this under 2008R2 which is basically the same as your
> W7-64 bit. I used local and remote drives to test the issue but to no
> Are you sure this isn't a BLODA problem which is triggered by the
> changes in 1.7.9?
> I just took a look through the changes between 1.7.8 and 1.7.9, and
> the list of changes which affect filesystem access is pretty small:
> 2011-03-14 Corinna Vinschen <...>
> * fhandler_disk_file.cc (fhandler_base::fstat_by_handle): Only use
> file id as inode number if it masters the isgood_inode check.
> 2011-03-08 Corinna Vinschen <...>
> * fhandler.cc (fhandler_base::open): When creating a file on a
> filesystem supporting ACLs, create the file with WRITE_DAC access.
> Explain why.
> * fhandler_disk_file.cc (fhandler_disk_file::mkdir): Ditto for
> * fhandler_socket.cc (fhandler_socket::bind): Ditto for sockets.
> * path.cc (symlink_worker): Ditto for symlinks.
> * security.cc (get_file_sd): Always call GetSecurityInfo for directories
> on XP and Server 2003. Improve comment to explain why.
> So, is it possible that the request for WRITE_DAC access in the call to
> NtCreateFile triggers some hiccup of your virus checker? It could easily
> explain both effects.
The machines I'm observing this on are not running anti virus (or any of
the listed BLODA) software as they are used internally as build
(compile) only servers, but (as I just found out) do run indexing.
Turned indexing off and will go back to 220.127.116.11 on one of the machines
What also may be different that these machines are virtual machines
running on an ESX server with disks on a SAN, which results in disk
access times being almost comparable to SSD times.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
More information about the Cygwin