On Sunday 31 August 2008 18:22, Brian K. White wrote:
...
I think the OP already knew about compressed filesystems. The question was not about compressed filesystems. It was about treating a zip file as a directory.
Correct.
.... Although I don't think I have much use for mounting an archive as a filesystem, it's interesting to know about none the less. Maybe it's slightly fewer keystrokes for working on initrd's which are now cpio files instead of ext2 filesystems.
In my case, the need arose when I devised a set of scripts (additions to existing ones, actually) to facilitate large-scale experimentation within a very large space of options and search heuristics for a theorem-proving system. Prior to this, we'd alter the options or the search heuristic and run test after test. Sometimes we'd hit on a propitious combination and later not be able to recreate it. So I augmented the invocation scripts to maintain a log of compressed test results. Each run of the prover generally produces many files, including HTML renderings of the proofs discovered or, failing a successful attempt, the statistics describing the unsuccessful effort. With that scheme in place, I wanted a convenient way to access this history of our experiments. I started by trying to create some scripts that would help, but they proved cumbersome, so I asked about better-integrated, more transparent solutions, with reference to my recollection about a similar capability integrated via Windows Explorer. The "archivemount" command (relying as it does on the libarchive library and on FUSE) was nearly ideal. The only thing I could possibly wish for beyond what it provides is some kind of automatically triggered invocation (akin to NFS auto-mounting), but given the huge number of archives I have to deal with, that probably would entail its own set of complications and down-sides. E.g., knowing when to unmount an archive that is no longer in use. I have one experimental log which currently has 122 gzip-compressed TAR archives, and archivemount can simultaneously provide them all (not that I'd typically do that, but it was easy enough to try with a wild-card invocation). Each one requires a running instance of the archivemount program. One final gap is the following. Compare the (elided) output of "mount" with that of "df." ("am" is my cover script for invoking archivemount): % am log/latest.tar.gz % mount LABEL=Root10 on / type xfs (rw) ... /dev/sda1 on /repo type reiserfs (rw) /dev/sdb1 on /root93 type xfs (rw) /dev/sdd1 on /root91 type xfs (rw) /dev/sdd2 on /home type xfs (rw) /dev/sdd3 on /dar type xfs (rw) ... archivemount on /dar/tau/tst/New/log/latest type fuse (rw,nosuid,nodev,user=rschulz) % df Filesystem 1K-blocks Used Available Use% Mounted on LABEL=Root10 35895684 17805508 18090176 50% / /dev/sda1 293008588 106776492 186232096 37% /repo /dev/sdb1 20962560 11336984 9625576 55% /root93 /dev/sdd1 11962304 6421104 5541200 54% /root91 /dev/sdd2 11961344 8485132 3476212 71% /home /dev/sdd3 11961344 4456652 7504692 38% /dar df: `/dar/tau/tst/New/log/latest': Function not implemented I gather from this that archivemount does not implement a file-system switch function used by the "df" command.
-- Brian K. White
Randall Schulz -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org