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 Message-ID: <42F75183.6010804@byu.net> Date: Mon, 08 Aug 2005 06:35:15 -0600 From: Eric Blake User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) MIME-Version: 1.0 To: cygwin AT cygwin DOT com Subject: findutils vs. /proc/registry Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A while ago there was a thread that complained that 'find /proc/registry' did not work. I've done some debugging, and found more details. Also, the upstream maintainer has added a patch to use gnulib fts() instead of his own directory traversal code on CVS, which improves, but doesn't fix, the behavior. To begin with, the current version of find is failing to recurse into registry directories: $ cd /proc/registry/HKEY_CLASSES_ROOT/\*/shellex/ContextMenuHandlers $ find . . ./Offline Files find: ./Offline Files: Is a directory ./Open With find: ./Open With: Is a directory ./Open With EncryptionMenu find: ./Open With EncryptionMenu: Is a directory ./{a2a9545d-a0c2-42b4-9708-a0b2badd77c8} find: ./{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}: Is a directory I traced this to the fact that findutils() expects open(".", O_RDONLY) to succeed if a directory is readable (and that is my reading of POSIX as well), but cygwin is failing with EISDIR. Is there any way cygwin can be patched to allow open(".", O_RDONLY) to succeed? With CVS findutils, the new fts() code uses opendir() instead of open() to save state on which directory is being traversed, and this lets find finally browse into subdirectories. But now the behavior is different depending on whether the current working directory is in /proc/registry or not: $ ~/findutils/find/find "`pwd`" /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files /home/eblake/findutils/find/find: /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files/@: No such file or directory /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With /home/eblake/findutils/find/find: /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With/@: No such file or directory /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With EncryptionMenu /home/eblake/findutils/find/find: /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Open With EncryptionMenu/@: No such file or directory /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/{a2a9545d-a0c2-42 b4-9708-a0b2badd77c8} /home/eblake/findutils/find/find: /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/{a2a9545d-a0c2-42b4-9708-a0b2badd77c8}/@: No such file or directory $ cd $ ~/findutils/find/find "$OLDPWD" /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files /proc/registry/HKEY_CLASSES_ROOT/*/shellex/ContextMenuHandlers/Offline Files/@ Hmm, when started from within /proc/registry, find sees every file, but reports an error that leaf nodes are returning ENOENT. But when started from elsewhere, find is able to report on the leaf nodes without error, but only traverses the first directory instead of the entire tree. And that's where where I got stuck debugging. Since /proc/registry is virtual, the notion of current working directory being a virtual directory is lost as soon as gdb or strace is used (reverting to pwd of the last non-virtual directory), so under gdb, I'm always seeing the second behavior. I have no idea whether the bug exposed by the CVS find is in find, or in cygwin, but it is sure annoying that there are two behaviors, and that only one of those behaviors is visible from gdb and strace. - -- Life is short - so eat dessert first! Eric Blake ebb9 AT byu DOT net -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC91GD84KuGfSFAYARAtg2AJ9y0hRIuoCQlRd1gMQRTeUjo8uJTQCfZR0f AtxUt1B/wEACAw1yrddIbtc= =Yvfn -----END PGP SIGNATURE----- -- 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/