Re: Fwd: findutils bug

[rowol]

Thanks for looking at this James.
I'll send a report to Cygwin at some point.

For now I'm using the find with gnuwin32 (native win32), which appears to
work.

Thanks!
Ross


> On 4/2/06, address@hidden <address@hidden> wrote:
>> > Did you mean to send a zero-byte strace.txt file as an attachment?
>> > It looks empty to me, at least.
>>
>> I've attached it again...
>
> Looking at the trace, we have this sequence of events...
>
>   840  534535 [main] find 208 get_file_attribute: file: v:\mp3
>   394  534929 [main] find 208 fhandler_base::fstat_helper: 0 = fstat
> (, 0x22EA40) st_atime=442D97BB st_size=0, st_mode=0x41ED,
> st_ino=3879944200, sizeof=96
>   414  535343 [main] find 208 fhandler_base::close: closing
> '/cygdrive/v/mp3' handle 0x6D0
>   885  536228 [main] find 208 fhandler_base::fhaccess: returning 0
>   414  536642 [main] find 208 fhandler_disk_file::opendir: 0x482358
> opendir (/cygdrive/v/mp3)
>   355  536997 [main] find 208 fhandler_base::open: (v:\mp3, 0x110000)
>  1035  538032 [main] find 208 fhandler_base::set_flags: flags
> 0x110000, supplied_bin 0x10000
>   399  538431 [main] find 208 fhandler_base::set_flags:
> O_TEXT/O_BINARY set in flags 0x10000
>   374  538805 [main] find 208 fhandler_base::set_flags: filemode set to
> binary
>   419  539224 [main] find 208 fhandler_base::open: 0 = NtCreateFile
> (0x6D0, 20080, v:\mp3, io, NULL, 0, 7, 1, 4000, NULL, 0)
>   355  539579 [main] find 208 fhandler_base::open: 1 fhandler_base::open
> (v:\mp3, 0x110000)
>  1526  541105 [main] find 208 fhandler_base::open_fs: 1
> fhandler_disk_file::open (v:\mp3, 0x10000)
>  1057  542162 [main] find 208 get_file_attribute: file: v:\mp3
>   409  542571 [main] find 208 fhandler_base::fstat_helper: 0 = fstat
> (, 0x22EC30) st_atime=442D97BB st_size=0, st_mode=0x41ED,
> st_ino=3885202216, sizeof=96
>
>
> Notice that the value of st_ino is different between the two calls to
> fstat().   This is triggering the logic within find that detects
> attempted race condition exploits (for example deleting a subdirectory
> and changing it to a symlink to something else).
>
> If v:\mp3 really had changed, this would be the right thing to do.  If
> it didn't changed, then in the end find is doing the wrong thing, but
> only because it is working on inaccurate evidence.
>
> However, I can't explain why Cygwin seems to be doing this as the
> explanation at http://www.cygwin.com/cygwin-ug-net/highlights.html
> seems to indicate that this should not happen (assuming that the
> fstat() implementation knows the filename of the open file).
>
> Anyway, I'm reasonably certain this this is a problem with Cygwin
> rather than findutils.
>
> Thank,
> James.
>