On Sun, 13 Aug 2000, Alan Cox wrote:
> > Quite frankly, _eventually_ we'll have to bite the bullet and handle
> > resource forks. Maybe HFS will continue to use the current setup. Who
> > knows? But wouldn't it be nice to have a unified way of handling it? And
> > complain all you like, but the HFS way just cannot be the unified way.
>
> 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.
Using colon-separated suffixes seems like a reasonable solution IMO.
> > 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
>
> 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(
Colons. I haven't seen any holes in that yet ;-)
Like the HFS approach, you can tar up an NTFS partition (with
multi-streamed files), unpack it to ext2 or whatever, tar it up again,
unpack to NTFS and you are left with exactly what you started.
It avoids breaking existing userspace tools (tar, cp etc).
It even makes porting things from NT easier - they see the extra streams
the same way they expect to.
Anyone got any objections to this??
James.
-
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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:31 EST