I think the principle of least astonishment dictates that the default behavior of existing tools match what they do on existing systems. That is, S_ISDIR should be the usual test applied by find and the like. I for one will be annoyed if I do "find . -name \*.o -print | xargs rm" and it goes into my translator-provided tar-file directories and removes the backup copies of my .o files.
(I am not going to delve into the standards today, but I can imagine it being the case that a careful reading of 1003.1+1003.2 mandates that find's decision to descend must match S_ISDIR. Of course that might be deemed irrelevant on any system where you've done a nonstandard thing like setting a tar-file translator.) GNU find certainly ought to have switches to make possible all the permutations of what you might really want to do given the Hurd filesystem semantics. That includes a switch to descend non-S_IFDIR directories, akin to `-follow' for descending symlinks to directories, as well as a switch to use O_NOTRANS, etc. I think it is a reasonable convention that a translator use the S_IFMT bits to indicate how it wants to be treated by normal POSIXish tools. That seems like a sane convention for the Hurd in the abstract, and it conveniently matches the de facto convention of all existing filesystem-using tools and presumption of users familiar with other POSIX systems. For tar-file directories and other such cases, it should be a command-line option to the translator so you can have it either way depending on what you want for a particular case. > Roland McGrath <[EMAIL PROTECTED]> writes: > > > Note, however, that this optimization in find will quite totally break the > > filesystem semantics presented by translators set on regular files. That > > is, a translator set on a regular file may well report S_IFDIR and so a > > find ought to treat it as a directory. But the underlying node isn't a > > directory and so doesn't have a .. node contributing to the containing > > directory's link count. > > This is a realy problem with find, and we should report it. > (Actually, we should try and provide a patch.) > > It opens a question: do we want the decision to hinge on whether > S_IFDIR is returned? The other thing is to test on whether it really > is a subdir. (Note that my earlier note about st_nlink is about > subdirs, S_IFDIR.) > > A real subdir, of course, is one that supports directory operations. > > Perhaps find should support both versions, and should have a user > option to say which. (That is, it being find, it should have > predicates to detect which, and then a sane default.) It begs the > question of "what is the default", but whatever it is, it should be > the same as is used by things like chmod -R and so forth. > > I'm inclined to say the default should be to work on all real subdirs, > whether they label themselves with S_IFDIR or not. > > Thomas _______________________________________________ Bug-hurd mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-hurd
