Todd Inglett <[EMAIL PROTECTED]> writes:
> or ioctl or system call that does an "extended" readdir? You could
> provide inode, mode bits (or at least file type) and name. Or if you
> don't like that, how about providing a "..." virtual entry in each
> directory (perhaps not visible by a normal readdir, but that can be
> looked up nonetheless) that returns this information if you do an
> opendir/readdir on it. The file types could be encoded in magic inode
> numbers that you *do* have control over. Then at least we can write
> reasonably useful file browsers for DFS....
I like the pioctl approach better than some magic hidden virtual file
name. I have remarked on a number of occasions that the VFS (and even
VFS+) interface is not quite rich enough. For example, it would be
nice to know in the filesystem whether the user really intends to stat
every file in this directory (or worse, really wants the first 100
bytes of every file...), or whether the user is doing a "cp" of a
file--this set of reads and writes is causally related... We can
guess fairly effectively that somebody is doing "ls -CF", but don't
dare even try to identify "cp".
> On yet another semi-related note, is @sys still supported in DFS?
yes
