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/
This archive was generated by hypermail 2b29 : Tue Aug 15 2000 - 21:00:31 EST