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, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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. > _______________________________________________ Bug-findutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-findutils
