Roland McGrath <[EMAIL PROTECTED]> writes:
> 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 "f
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
Neal H Walfield <[EMAIL PROTECTED]> writes:
> > Implementing that you how suggested would be more or less a rewrite..
>
> Although admittedly, it is an excellent approach.
Well, that remains to be seen. But it is the reason for having the
directory notification RPC's at all. (And also so that
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Implementing that you how suggested would be more or less a rewrite..
Not every filesystem is even able to implement the directory
notification RPC's, so the kind of strategy you're using will still be
necessary for those cases.
_
> Implementing that you how suggested would be more or less a rewrite..
Although admittedly, it is an excellent approach.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Oh, well you only need that once.
>
> My thought has always been that an efficient shadow directory would
> scan the underlying directories once on startup, and after that
> would maintain correct information through the change-notification
> mec
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > But that's not so bad. It doesn't mean checking every single entry
> > in both directories; it means checking only those elements which are
> > duplicated names.
>
> Sure; I was referring to the
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> But that's not so bad. It doesn't mean checking every single entry
> in both directories; it means checking only those elements which are
> duplicated names.
Sure; I was referring to the dir_readdir()s needed for a simple
directory lookup...
Moritz Schulte <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
>
> > Why is it not sufficient to add up the link counts of the shadowed
> > directories (compensating for the -2 term) and use that?
>
> In the case where we have file entries with the same names in t
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Why is it not sufficient to add up the link counts of the shadowed
> directories (compensating for the -2 term) and use that?
In the case where we have file entries with the same names in the
shadowed directories, some entries get shadowedd and
Moritz Schulte <[EMAIL PROTECTED]> writes:
> Actually i cared about the performance aspect. If there are shadowed
> directories, which contain _many_ entries and the user simply looks up
> that directory in shadowfs, shadowfs would have to first read _all_
> the directory entries of _all_ of the
[EMAIL PROTECTED] (Thomas Bushnell, BSG) writes:
> Posix is looser than this, as Roland points out, but absent a really
> good reason (and "it's a bother to code" is probably not a really good
> reason) we should provide consistent sane behavior.
Actually i cared about the performance aspect. If
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
Roland McGrath <[EMAIL PROTECTED]> writes:
> By my reading of 1003.1-1996, st_nlink should be "the number of directory
> entries that refer to the file". In a case like this, I think it's pretty
> open to interpretation what constitutes a directory entry; there always
> might be extra entries in
Oy! I had no idea find did that, though I suppose it is reasonable.
By my reading of 1003.1-1996, st_nlink should be "the number of directory
entries that refer to the file". In a case like this, I think it's pretty
open to interpretation what constitutes a directory entry; there always
might
Roland McGrath <[EMAIL PROTECTED]> writes:
> I don't think the st_nlink value on a directory matters much to any
> user.
Sorry, i should have been more precise in my first mail.
GNU find for example uses that value. The wrong (too small) st_nlink
value was the cause for find not searching in th
I don't think the st_nlink value on a directory matters much to any user.
___
Bug-hurd mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/bug-hurd
17 matches
Mail list logo
