untarring symlinks with ../ fails randomly, silghtly OT

[Ryan Johnson]

On 04/07/2011 6:46 AM, 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/1.7.9.1 to cygwin1.dll/1.7.8.1
>> 	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
> avail.
>
> 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:
>
> [snip]
>
> 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.
I have also seen the rm -rf problem occasionally on my w7-64 machine, 
and I don't think anything from BLODA is installed.

However, I haven't noticed the issue since disabling the search indexer 
on my machine. I did this on the hunch that I often delete large 
directory trees which aren't very old (e.g. after untar/configure/make 
of some source package), and that it wouldn't be a big surprise if 
indexing and cygwin's rm don't mix for whatever reason.

Thoughts?
Ryan


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