Some filesystem thoughts

[Ronald Klop]

On Wed, 20 Feb 2013 20:26:42 +0100, Radio młodych bandytów  
<radiomlodychbandytow at o2.pl> wrote:

> Hello,
> I'm a pretty fresh Unix user, suffering from productivity loss caused by  
> changing OS. I dearly miss a couple of facilities that I had implemented  
> in my file manager (Total Commander) and sought a file manager that  
> could replace them. I'm pretty sure there's none. I found that Unix does  
> some of them at the OS level and that's a superior way. But with others  
> it doesn't; some file managers implement them by themselves, much like  
> TC (not well enough, but that's another rant), but I think that for  
> them, OS is the right place too and that's what I'd like to talk about.  
> I come with a free idea that I think would be awesome to have  
> implemented, while not being sure it even can be implemented sensibly  
> within Unix. Maybe I miss something? Maybe the idea ain't good? Maybe  
> there are things that do the job well enough already and I just miss  
> them?
>
> Anyway, here's the story:
>
> Total Commander's filesystem plugins are awesome. They enable users to  
> manage remote / virtual resources just like remote filesystems. FTP,  
> websites, process list, calendar; the variety is rich.
> In Unix, there are equivalents for some of them; the ones that mattered  
> the most for me can be usually simulated by mount.
> And that's a better way because when mounted, they can be used by any  
> program, not just file manager. I'm sure that all people here are used  
> to enjoying the benefits of this approach, though for me they are novel.
>
> The other thing - packer plugins. They allow treating archives like  
> directories. Again, there are many useful ones, some obvious (like  
> zips), some not so much. I treated my executables as directories, which  
> enabled me to easily manipulate resources stored inside. Especially  
> useful when hacking closed-source Delphi programs as they contain lots  
> of GUI code stored directly (The name 'TNASTYNAGSCREEN' will stay in my  
> mind for long). Or extracting icons. Or doing many other things that are  
> necessary to play with closed source code, but less relevant in Unix.
> There was a steganography plugin storing data inside images. A plugin  
> for generation and browsing of file lists. A Java decompiler. And a  
> great variety of others.
>
> Unix file managers offer similar, though not so rich options. Yet I  
> think it's not their job. Like with mounting, there's great benefit from  
> being able to use standard tools with them.
> Some write things like zipfs, but I think it's wrong.
> First, typing a command is cumbersome. Second, even if it was automated,  
> mounting needs a mount point. The only good one is the file itself;  
> working with a dozen (or thousand) of archives in a single directory is  
> a norm for me. Switching dirs back and forth would be very disruptive.  
> Breaks relative paths. And so on.
>
> The way I see it is not to treat files as streams of bytes. That's not  
> what they are, files have meanings and there are tools that bring them  
> out. A picture is a stored emotion. OK, there are no tools for that yet.  
> But it is also an array of pixels. And a container with exif data. And  
> may be a container with an encrypted archive. And, a stream of bytes too.
> They have multiple facets.
> I think that it would be useful to somehow expose them to applications.
> Wouldn't it be useful to be able to grep through pdfs in your email  
> attachments?
> Mass-edit music tags with sed? Manually edit with your favourite text  
> editor instead of the sucky one-liner provided by your favourite music  
> player?
> How about video players being able to play videos by reading them in  
> decoded form directly from the filesystem instead of having to integrate  
> a significant number of complex libraries to provide sufficient format  
> coverage?

Creative ideas.
Part of what you want is in fusefs (mounting of files to edit their  
content). And part is implemented in e.g. KDE (integrated support for  
various file types in fulltext search and tagging of files/metadata, etc.).
The chances of having all these complex libraries integrated in the  
FreeBSD OS are close to zero I presume. But I am not in a position to  
decide about that.
I think you can't expect the OS to serve everybody's detailed wishes. The  
OS serves files and user programs know what to do with them.

Ronald.