Ben Fennema wrote:
> Well, theres a few other pain in the butt things to consider.
> One, I have to keep track of the file sizes of all the files in the streams
> directory (there is a record of the total size of the main file + all
> streams) I guess I'd need a link from the stream file to the main file,
> so when the stream file gets written out and the size differs from the
> on-disc size, I adjust the main file total size. Sounds like race city :)
Oh I see, these aren't "forks" like on a Mac, they're "streams" like the
ones not used on NTFS.
That's completely orthogonal to the "file as directory" problem. The
file size thing (and presumably data integrity too) is all about files
which alias each other or represent each other's contents.
You don't need "file as directory" for that. And the solution should be
kept separate.
BTW, your hack for accepting lookup on the file plus "#STREAM" extension
suffurs from exactly the same aliasing problem -- and shows that it is
orthogonal to the directory issue.
> The link count of a file w/ stream is + 1, so the whole thing will just
> get pruned from the tree but still exist *laf* (Of course phyiscal link
> count doesn't have to equal inode->i_count)
Sure, but the generic vfs code checks S_ISDIR to decide what to do.
I'd have to read the vfs code some more to decide if unlink() on a
!IS_DIR will delete the child dentries.
> Removing the file is supposed to unlink the stream directory and all files
> in it.
Makes sense from a user point of view. This may require a new VFS
function to recursively delete child dentries, or maybe that works
already -- it does have to recursively delete _negative_ dentries on
rmdir after all.
> > Overall summary
> > ---------------
> >
> > The obvious anomalies for the user experience are chdir/fchdir. I think
> > they should be changed to call __namei() with
> > LOOKUP_DIRECTORY|LOOKUP_FOLLOW, instead of just LOOKUP_FOLLOW as they do
> > now. (namei(s) just calls __namei(s,LOOKUP_FOLLOW)). And drop the
> > S_ISDIR check.
> >
> > With that tiny change you could chdir into your UDF directories
>
> It looks simple enough. Prolly still not a good idea though, but
> probably not bad for testing.
I provided it to work around your Glibc opendir problem. You could just
as easily change Glibc.
It shouldn't make any difference to the kernel because namei() will
happily go through your pseudo-directories already. In a sense, chdir
is just a convenience.
-- Jamie
