Mail Archives: cygwin/1997/01/24/01:06:28
Tim Newsham wrote:
>
> > In this case it's not find that is trying to create the file 'out',
> > but rather the shell.
>
> The problem is not creating the file. Perhaps the description
> was misleading:
>
> % find . -name '*.c' >& out
>
> That command runs to completion. The file 'out' is created.
> Now if you look in the file out you see:
>
> % cat out
> find: out: Permission denied
>
> (may not be exact, this is from memory).
> The file out contains the output from the find command. The
> find command was for some reason unable to perform an operation
> on the file out. (Perhaps because 'out' is an open file
> held open by the shell?). At any rate, the bug
> is definitely find, not the shell.
find uses the lstat system call, and the cygwin implementation
opens the file and actually reads it in order to see whether it is a
symlink (now you know why find takes so long). symlink_check dies
opening a file opened for writing (a piece of Miscrosoft brilliance
that helps unix weenies win the advocacy wars). Note that
find -follow doesn't get the error; it uses stat, which silently
assumes that, if it can't open the file, it isn't a symlink.
I think the two cases ought to be consistent; i.e., lstat should
report an open symlink as a regular file (the alternative, of
stat returning an error on any open file, is unpleasant).
Or, somehow tell the OS to allow files open for writing to be open
for reading.
--
<J Q B>
-
For help on using this list, send a message to
"gnu-win32-request AT cygnus DOT com" with one line of text: "help".
- Raw text -