On Thu, Aug 26, 2004 at 10:53:48AM +0300, Markus Törnqvist wrote:> On Thu, Aug 26, 2004 at 12:32:00AM -0500, Matt Mackall wrote:> >What it breaks is the concept of a file. In ways that are ill-defined,> >not portable, hard to work with, and needlessly complex. Along the> >way, it breaks every single application that ever thought it knew what> >a file was.> > It breaks the concept of a file. In ways that offer more versatility,> challenge the imagination to make even better progress and keeps> Linux competing with competitors who are implementing this stuff> as we speak.

Sigh, it really isn't all that groundbreaking. The only special featureis the fact that it introduces directory hardlinks.

Just turn the phrase 'file-as-dir' around and you might see the point.As far as userspace is concerned the implementation would behave 99%identical if we provided a 'dir-as-file' semantics. i.e. opening adirectory without 'O_DIRECTORY' would return a filehandle to a defaultfile within the directory. Something like open("/path/to/dir", O_RDONLY)would be translated to open('/path/to/dir/_contents', O_RDONLY).

So I could simply replace all my files with directories and move theoriginal file contents into a '_contents' file. Applications can stillopen them by the same name, although the attributes would look a bitdifferent. Poof, we have the same file-as-dir concept, but now we playfair with the existing VFS and don't introduced races/deadlocks andother issues. Also existing backup tools will be able to back up andrestore these 'streams'.

(btw. the same could be implemented completely in userspace, forinstance in glibc. Whenever an open call gets an EISDIR error, simplyretry the open, but this time with /_contents appended).

> I for one would truly welcome the coming of thumbnails and descriptions> in picture files, because I have a real-life project going on where> that would be extremely handy to have in the actual file.

> >Find some silly person with an iBook and open a shell on OS X. Use cp> >to copy a file with a resource fork. Oh look, the Finder has no idea> >what the new file is, even though it looks exactly identical in the> >shell. Isn't that _wonderful_? Now try cat < a > b on a file with a> >fork. How is that ever going to work?> > Then I guess OS X ships a broken implementation of cp, yes?

No cp is working just fine, there is no copy syscall in the VFS, so anyfile system specific features such meta data streams will have to behandled by the application.

So at some point 'cp' will have to be taught about macos resource forks,posix acls, xattrs, afs acls, reiserfs file-as-dir, freebsd attributes,samba/ntfs streams. And possibly even learn the semantical differencesbetween these so that it can copy metadata between the various filesystems types.