Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com From: ericblake AT comcast DOT net (Eric Blake) To: Dave Korn , skilover AT softhome DOT net, cygwin AT cygwin DOT com Subject: RE: findutils still broken Date: Thu, 21 Apr 2005 17:39:57 +0000 Message-Id: <042120051739.4433.4267E56D000394CD0000115122069984990A050E040D0C079D0A@comcast.net> X-Authenticated-Sender: ZXJpY2JsYWtlQGNvbWNhc3QubmV0 > 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/