Messages in this thread | | | Date | Sun, 13 Aug 2000 15:07:06 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: NTFS-like streams? |
| |
On Sun, 13 Aug 2000, Alan Cox wrote: > > I'd very much like it to be unified. I can see that very well. It needs to > be unified in a way I can serve it over NFS to boxes that dont make that > assumption and create the same layout trivially on a non resource forked > fs.
Fair enough. I do think that it is basically impossible to try to create a non-POSIX filesystem with POSIX semantics. There's always going to be some problem - exporting resources over NFS (that doesn't know about them) is going to cause some quite interesting problems with caching issues on the clients we export them to, for example.
> > At the very least, I hope the virtual ".resource" directory is the same > > physical inode as the directory it resides in, because otherwise the basic > > "dir->i_sem" concurrency protection simply won't work. > > If it has the same inode number lots of other stuff breaks so I fear it doesnt
Ehh.. The "lots of stuff breaks" is, I assume, basically again just "tar". Nothing else really ever tends to care about inode numbers.
Note that the tradeoff of "can potentially cause filesystem corruption" vs "well, at least 'tar' is happy with the layout" is not a trade-off where I would have considered the happiness of 'tar' to be of all that noticeable importance.
But apparently that's the choice the HFS filesystem has made. Shades of Windows, in my opinion: "yeah, we know it is broken, but we preferred some hard-to-trigger filesystem corruption to breaking a legacy program that couldn't understand the new filesystem features".
> Im not arguing about needing to do something. I just think the solutions so > far all have large holes in them. And no - I dont have a better one to offer 8(
We could in theory play games with "readdir()". Do things like return two entries with the same name, and with different st_mode information. Now THAT would be confusing, but it might fool "tar" into doing exactly the right thing without any changes, in fact (first opening the file as a plain file and saving that away, then opening the same file as a directory and saving that away).
Yeah, I think POSIX would consider that a no-no ;)
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |