Messages in this thread | | | Date | Sun, 13 Aug 2000 12:42:44 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: NTFS-like streams? |
| |
On Sun, 13 Aug 2000, Alan Cox wrote:
> > But "tar" won't even _see_ the thing. Unless "tar" starts to know about > > S_IFCOMPLEX. In which case it's a non-issue. > > oh wonderful. So you've just broken my backup scripts. Congratulations.
Alan.
Calm down a moment, and THINK.
How hard do you think it is to make the tar-test that does
if (S_ISDIR(st->st_mode)) { ... traverse into directories .. }
instead be
#ifdef S_ISCOMPLEX #define CAN_TRAVERSE(x) (S_ISCOMPLEX(x) || S_ISDIR(x)) #else #define CAN_TRAVERSE(x) (S_ISDIR(x)) #endif
...
if (CAN_TRAVERSE(st->st_mode)) { .. traverse into directories .. }
and suddenly tar _can_ handle resource forks. Sure, you'll need some extra logic to handle the complex files data too, but really, Alan.
What's the advantage, I hear you say?
The above will work on HFS. But so will the current "tar". Resource forks and all.
The above will -also- work on NTFS. And the current setup will never do that.
> tar is already backing up my HFS test partition, including the resource > forks.
..and it can do so.
The thing is, right now resource forks are only exported on HFS. As far as I know, the Linux NTFS driver doesn't even try. But people are starting to be more and more interested in supporting NTFS in a real way, rather than the partial support it has now. You-know-who etc.
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.
There are actually problems with the current HFS hackery: one of the problems is that because it splits things up in different directories, you have multiple dentries pointing to the same inode. That's fine: the dentry code has no trouble with that per se (hard links), but I suspect it causes races on create/remove.
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.
(To me it looks like that isn't the case. Race city. Nobody probably cares, but it's an example of the fact that HFS is actually buggy as it is implemented right now. Exactly because the VFS layer doesn't understand what it is that HFS is trying to do).
Do you see the problem now? Is pointing you to a real bug enough?
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/
| |