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.
>
> > 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(
What about to use:
dir/file
dir/#file/Icon
dir/#file/Info
but leaving the exact semantics Linus proposed for S_ISCOMPLEX solution?
The only needed additions I think are the rules:
- creating dir/#file implies the creation of an empty dir/file (if it
does not exists)
- no regular files can be created with names beginning with # (or
another magic char, BTW a suffix instead of a prefix would keep sorting
happy)
In this way we can use NFS mounting, tar, cpio, and all current stuff
without changes.
-- Abramo Bagnara mailto:abramo@alsa-project.orgOpera Unica Via Emilia Interna, 140 Phone: +39.0546.656023 48014 Castel Bolognese (RA) - Italy Fax: +39.0546.656023
ALSA project is http://www.alsa-project.org sponsored by SuSE Linux http://www.suse.com
It sounds good!
- 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:32 EST