This is the mail archive of the
mailing list for the Cygwin project.
RE: findutils still broken
- From: ericblake at comcast dot net (Eric Blake)
- To: Dave Korn <dave dot korn at artimi dot com>, skilover at softhome dot net, cygwin at cygwin dot com
- Date: Thu, 21 Apr 2005 17:39:57 +0000
- Subject: RE: findutils still broken
> 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
> 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
> EXIT STATUS
> find exits with status 0 if all files are processed
> 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
$ 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
ClearCaseMenu Offline Files Open With EncryptionMenu
LDVPMenu Open With PowerArchiver
./shellex/ContextMenuHandlers/Open With EncryptionMenu:
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html