lkml.org 
[lkml]   [2000]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: NTFS-like streams?


On Sat, 12 Aug 2000, Alexander Viro wrote:
>
> You know what tar(1) will do with you for that, don't you? Same ->st_ino
> with different contents... And unlike procfs, here tar is a Reasonable
> Thing(tm).

But "tar" won't even _see_ the thing. Unless "tar" starts to know about
S_IFCOMPLEX. In which case it's a non-issue.

Remember: unix-only programs will only see the regular data side. They
won't ever see the other resource forks at all. Ergo, they cannot break.

Programs that are aware of S_IFCOMPLEX are aware of it. Ergo, they cannot
break.

In short: not a problem.

> > We've had similar issues with the MS-DOS filesystem just because it
> > doesn't have some of the attributes at all. You can think of resource
>
> So we did. I also remember the hell we had there due to the weird aliases
> mess.

Oh, name case-insensitivity is _much_ worse than forks will ever be.

> Oh, yes. Linus, I would _really_ ask you to postpone the activity in that
> direction until
> a) ->revalidate() interface (along with its races) is sorted out
> b) ->getattr() will be in place and used by VFS
> c) icache hashing by ->i_dev issue is sorted out, quite possibly
> along with the ->st_fstype thing

Note that no way is this going to happen until 2.5.x anyway, so don't
worry.

And it won't happen at all unless somebody starts to care more about
things like HFS than historically people have cared so far. NTFS may end
up being the thing that makes us do this. But it may be that even NTFS
isn't important 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:1.296 / U:0.028 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site