> Ah. No, you absolutely shouldn't say it "crashes", because it does not
> "crash". Misdescribing a bug is the slowest imaginable way of getting it
> fixed!
>
> Particularly so in this case, because I don't see why find *shouldn't*
> return an exit code of 1 when it's had all those errors. Have you read "man
> find"?
>
>
> EXIT STATUS
> find exits with status 0 if all files are processed
> successfully,
> greater than 0 if errors occur.
>
>
> Presumably the reason that this behaviour is new is that there used to be
> a bug that stopped it even attempting to recurse those dirs, because nothing
> with '*' in it could ever be a valid filename.
Contrary to your statement, /proc/registry/HKEY_CLASSES_ROOT/*/ is a valid
directory name (but you sure have to be careful with shell quoting to actually
get there). My first guess is that there might be some bug in the readdir()
implementation for the /proc filesystem. Also, I've noticed that some cygwin
syscalls are sloppy, and change errno to EISDIR even when they are successful.
POSIX allows implementations to have this sloppy behavior (change errno even
on success) unless explicitly stated otherwise (although I think it should be
discouraged), so a portable application must assume that errno is invalid for
reading unless either a) the syscall gave indication that an error occurred and
errno is valid (by returning -1 or some other known indication) or b) the
application set errno before the syscall, and the syscall is documented as not
changing errno except on error. readdir() is documented as not changing errno
except on error when the return value is NULL, but is allowed to change errno
when the return value is non-NULL. So, either cygwin's /proc filesystem is
falling afoul of POSIX requirements on readdir(), or find is non-portable and
is wrongly assuming that an errno changed to EISDIR even on a non-NULL return
from readdir() means an error occurred. I still don't know if the error is in
find(1) or in cygwin1.dll, but don't have time to research further at the
moment.
I also noticed while trying to pin down a more exact cause of the bug that
strace behaves oddly when your current working directory is in /proc or any
other virtual file system. On further thought, it wasn't entirely unexpected:
because strace is a windows only program, it assumes that the most recent
Windows current directory is correct, because it has no way to know what the
cygwin current directory should be. However, this makes it very hard to try
and figure out why find is failing, when bash thinks my cwd is inside of
/proc/registry but strace does not. So it would be awesome if strace could be
patched to tell its cygwin children what the correct current working directory
should be.
$ cd /tmp
$ cd /cygdrive
$ /bin/pwd
/cygdrive
$ strace /bin/pwd |grep cwdstuff
62 9680 [main] pwd 440 cwdstuff::get: posix /tmp
93 9773 [main] pwd 440 cwdstuff::get: (/tmp) = cwdstuff::get (0x22EC40,
260, 1, 0), errno 0
363 63369 [main] pwd 440 cwdstuff::get: posix /tmp
118 63487 [main] pwd 440 cwdstuff::get: (/tmp) = cwdstuff::get (0x100A01C0,
-1, 1, 1), errno 0
One parting thought - maybe cygwin is correct and find is buggy, considering
that ls(1) has no problems recursing in /proc/registry, and it uses readdir()
as well:
$ cd /proc/registry/HKEY_CLASSES_ROOT/\*
$ ls -R
.:
AlwaysShowExt InfoTip shellex
./shellex:
ContextMenuHandlers PropertySheetHandlers
./shellex/ContextMenuHandlers:
ClearCaseMenu Offline Files Open With EncryptionMenu
LDVPMenu Open With PowerArchiver
./shellex/ContextMenuHandlers/ClearCaseMenu:
@
./shellex/ContextMenuHandlers/LDVPMenu:
@
./shellex/ContextMenuHandlers/Offline Files:
@
./shellex/ContextMenuHandlers/Open With:
@
./shellex/ContextMenuHandlers/Open With EncryptionMenu:
@
./shellex/ContextMenuHandlers/PowerArchiver:
@
./shellex/PropertySheetHandlers:
ClearCasePage {3EA48300-8CF6-101B-84FB-666CCB9BCD32}
CryptoSignMenu {883373C3-BF89-11D1-BE35-080036B11A03}
{1F2E5C40-9550-11CE-99D2-00AA006E086C}
./shellex/PropertySheetHandlers/ClearCasePage:
@
./shellex/PropertySheetHandlers/CryptoSignMenu:
@
./shellex/PropertySheetHandlers/{1F2E5C40-9550-11CE-99D2-00AA006E086C}:
./shellex/PropertySheetHandlers/{3EA48300-8CF6-101B-84FB-666CCB9BCD32}:
./shellex/PropertySheetHandlers/{883373C3-BF89-11D1-BE35-080036B11A03}:
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
