Re: The argument for fs assistance in handling archives

[Helge Hafting]

David Masover wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Helge Hafting wrote:
> [...]
> | You don't need kernel support for cd'ing into fs images.
> | You need a shell (or GUI app) that:
> | 1. notices that user tries to CD into a file, not a directory
> | 2. Attempts fs type detection and do a loop mount.
> | 3. Give error message if it wasn't a supported fs image.
>
> You can argue this about FS plugins, too.  You don't need kernel support
> for cryptocompress, for example.  Just have a fifo farm.  Every file
> that has compression turned on is actually a named pipe, the original
> file is hidden (starts with a dot), and you have a script running to
> each fifo which runs zcat.

Eww.  A shell/filemanager supporting fs images is one running program.
The fifo farm is one per file.  Ouch.

> The kernel support (read: interface) is just cleaner in some ways.
>
> In the loop mount example, it isn't universal -- the user can't CD into
> a file if they use the wrong shell, and two different shells might make
> two different mounts.  How many mounts before we run out of loop devices?

This limitation apply to the kernel interface too.  But you can 
configure for an
arbitrary number of loop mounts anyway. The user will have to mount
using the correct tool - after that the door is opened for anything.

> In the cryptocompress example, there's no caching or compress-on-flush
> optimization, and it isn't entirely transparent to anything.  It doesn't
> look like a file, it looks like a fifo.  ls will make it look yellow. 


Even the kernel supported "cd into fs images" has problems.  How should
the kernel know which files you want to support with mounting, and which
ones are the wast majority of plain files?   A file manager doesn't
have to do this fully automatic, it can have a button/hotkey for "loop 
mount this".
So the user will have to tell it what to do, but in a much easier way
than typing "mount -o loop . . . "  The file manager can also ask for
encryption keys - something the kernel cannot do because it doesn't
know what user interface(s) is in use by the process that attempts the "cd".
There may be one interface (stdin, X) there may be both, i.e. something
started from an xterm can use both, there may be none, (the 
web/ftp/file-server
got a request for something inside a encrypted fs image.)

And even if the kernel can figure out the correct user interface, do we
want it to contain an X client for asking for keys? :-/

Helge Hafting

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/