Tim Tassonis wrote: >>>I don't think I missed the point, I just differ in the opinion as to at >>>what level the limitation has to be solved. As long as the linux (or any >>>other UNIX) VFS layer does not provide metadata information, you will >>>always have to work around it and put a layer on top of it. This very >>>same layer can just as well operate on remote systems, because most of >>>the time those remote systems have an even lousier, more old-fashioned >>>API than Posix. >>> >>> >>I'm sorry, but you're really missing my point. I'll try to give a better >>explanation: >> >>Most modern Unix file systems (e.g. UFS, XFS) and some Linux specific >>file systems (e.g. ext2/3, tho with limitations) already support >>extended attributes, which in effect means that they are able to store >>metadata. ... >> >> > >I knew that, I just didn't mention it, because I didn't think it was the >point of the discussion. > > > >>Whats even more interesting about *the point* is not that the file >>system is able to store metadata, but that the file system is able to >>provide metadata (not necessarily stored explicitly by the user). A >>simple example is the mime type detection here: If the file system (I >>use the term "file system" here to refer to the "VFS module") *can* >>provide this data, you'll have less trouble on the application layer. >> >> > >Absolutely true, I knew that too. But did you knowthat fuse supports >Extended attribute by means of getxattr() and setxattr() in order to >read/store metadata and the Solaris vfs has a similar mechanism? > > > >>The above requires fast access to the content of the document (atleast >>to the first ~256 bytes), which is not necessarily a problem for most >>local file systems, but will definitely be a problem for a directory >>with around 200 files on a FTP server. You may work-around a few of >>these problems by "guessing" the file systems type, but that'll (a) >>require a lot of system-dependent code and (b) require you to change the >>code everytime somebody comes up with another VFS module. And that's >>really not what makes up a stable and clean solution. >> >> > >Absolutely true. That's why it would be better left to the VFS/Fuse layer. > > > >>On the other hand, with a smart desktop VFS system, the various backends >>would determine the MIME type in whatever way is best suited for this >>backend and pass it to the application (for example, KIO already does >>this). This way you don't have one single MIME detector with ~1000 >>#ifdef's in the end, and you can take advantage of backends that already >>provide the required data (e.g. an SVN backend would already provide the >>MIME-type and there's no need for detecting it at all). >> >> > >Same goes with an svn FUSE filesystem. > > > >>And there's a lot more than the MIME-type to say about a file, and most >>of this is highly backend-specific and far from what can be provided by >>any kernel-VFS-hack/work-around: For example, "Trash.DeletionDate" and >>"Trash.OriginalPath" for the trash: backend, "Audio.Artist", >>"Audio.TrackNo" and "Audio.Title" for the cd: backend, and so on. >> >> > >Could all be done using extended attributes, as in NTFS. > > > >>Don't get me wrong, FUSE is a good temporary work-around and I recommend >>it to people that want to access smb shares easily now, but you must be >>aware of the fact that it's really only a temporary hack and by no means >>a solution for the next 20-30 years. >> >> > >I do think it _can_ be a solution for that. >Using extended attributes, FUSE can always export additional information >just as a desktop VFS can. And it has the benefit that the filesystem is >also available in any other environment apart from the desktop without >any special library, just by fopen() and stuff. That's why I hope it >_is_ the future. >But as always, the developers of fuse filesystems or desktop filesystems >will decide. If great desktop vfs modules appear and only poor fuse >modules, the vfs modules will be the future, because people will use them. >In this sense, right now, FUSE seems to have a slight advantage over >D-VFS ... > > Fuse is great because applications dont have to be changed. D-VFS is great because they have to, as a developer knowing my programs most likely has a fallback on what to do when a network stream is interrupted and such, and wont deal with it as ioerrors (and most likely die immediatly) is a good thing.
I like fuse, and I've even worked with it, but if d-vfs is the future, it's not a bad thing ;) >Bye and thanks for the attention >Tim > > >_______________________________________________ >Thunar-dev mailing list >Thunar-dev@xfce.org >http://foo-projects.org/mailman/listinfo/thunar-dev > > > _______________________________________________ Thunar-dev mailing list Thunar-dev@xfce.org http://foo-projects.org/mailman/listinfo/thunar-dev