> 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(
Alan
-
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