[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: findutils bug

From: James Youngman
Subject: Re: Fwd: findutils bug
Date: Mon, 3 Apr 2006 10:14:25 +0100

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]