Messages in this thread | | | From | "Rob Taylor" <> | Subject | RE: NTFS-like streams? | Date | Mon, 14 Aug 2000 18:31:15 +0100 |
| |
Michael Rothwell wrote: > > > myfile > > > and > > > myfile/resource > > > > > > > hang on, Am I just going mad or does this not seem really sensible > - i.e. if we > > allow the existence of an entity that is both a file and a > directory, it would > > be a sane generalisation of both HFS's forks and NTFS's streams...? > > Or. alternatively I could be going mad.... ;) > > > You're not going mad. But files w/named streams are not > directories. Open a file in vi. Open a directory in vi. > The latter is meaningless, right? But if you open a file > with streams in vi, it works. >
hmm. What I meant was an entity that has both data and directory information attached (I'm not a file system hacker, so this'll be in abstract terms..). lets call this entity a dfile for example purposes. say I create a dfile 'rob1'. I can open it in vi and edit it as if it was a normal file. I can also do 'vi rob1/teststream' and I'll be creating a new file teststream, that's inside rob1. If I was going to implement this in a standard unix-filesystem way, I'd have a special directory entry, but with the 1st inode (or an inode labelled with a 'magic character', say 0x07) pointing to the data. then doing 'vi rob1' would work as if rob1 was a soft link pointing to the inode with the data. Thinking about it, it could be pretty icky - it'd be effectively be like the below (if it was possible)
mkdir("rob1"); creat("rob1/\0x07", <whatever> ); link("rob1/\0x07","rob1"); //would add soft link info to the directory info
..not that I'm saying you would implement it on ext2.. but hopefully that clarifies what I mean a bit.. hmm...
Rob Taylor
- 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/
| |