Messages in this thread | | | Date | Tue, 25 Aug 2009 11:04:55 -0700 | From | Jeff Shanab <> | Subject | Re: Starting a grad project that may change kernel VFS. Early research Re: Starting a grad project that may change kernel VFS. Early research |
| |
Rik van Riel wrote: > Jeff Shanab wrote: > >> Updates start at the file and only work upwards back to root. How does >> the hardlink get traversed? > > A hard link is just a second directory entry linking to > the same inode. There are no back links from inodes to > the directory entries that point to them and they are > essentially indistinguishable from files that are not > hardlinked. > > Hard links have been done like this in pretty much every > Unix filesystem since the 1970's. > Right :-( I need a workaround but I am not sure how the sementics should be.
In my example where we have a directory structure like so, where file is the same.
test/foo/bar/file test/bar/foo/file
My example would result in the size showing up in each directory at the bar/file and foo/file level Then the two numbers are passed up to test and the test directory size would be wrong. There is no real way to handle this becasue the two files look the same to the filesystem.
I can even remove the initial file without effecting the other. Is there a refcount I can take advantage of in the inode?
Even then, I can't decide what the semantic is.
For example I could add a pie chart that changed with navigation into my gui file manager. This system would make that practical. How would I display this information usefully to the user. I suppose if they navigate into either subdir they see the file size, but somehow when they navigate up to the directory that holds subdirs that indirectly contain both of them, only 1 can be counted. The problem is that the top level directory will not be able to see the inodes of the individual files, it is lost in the aggregate.
Still thinking....
| |