Can Unix Mount .TAR.GZ and .ZIP Files? 18
rhadc asks: "We can mount filesystems. We are constantly downloading .zip files and .tar.gz's. Why can't we mount .tar.gz's or .zip files? Mounting compressed packages and archives would make installation of software a little easier. Depending on how it was implemented, it could also require less disk space than the current method: Download, unzip, work/play. I've been a C programmer for a while, although taking on a large filesystem-type project isn't something I have time for, right now." It's just a matter of some enterprising (or bored) hacker writing file system drivers which use /dev/loop*, isn't it? Are there any projects looking to do something like this? Programs that cheat and actually untar the file to a teporary directory don't count.
Roxen kind of does this. (Score:3)
--
AVFS (Score:3)
http://www.inf.bme.hu/~mszeredi/avfs/
Baz
dunno (Score:1)
I'm sure if its thought out and done right, it could be done read only, but read write access probily would be harder to do. I bet there are some restrictions on archive file structure. That could be gotten around by just rewriting the file All together.
-LW
Compressed Ext2fs on loopback + other solutions (Score:2)
There is a patch that should make it into Linux 2.4. It is included in VALinux's unsupported kernels from HJL [valinux.com] (as well as Ext3 and NFS, and don't forget the losetup/mount RPMs as well).
Otherwise, I just use Midnight Commander (mc) to peer into and even modify TAR, TAR.GZ, CPIO, RPM and other files. In fact, if you're serious about working on compressed files, why not get into RPM where you can script (among other things)?
-- Bryan "TheBS" Smith
Feasable, but practical? (Score:1)
-The LionMan
Re:The User File System (Score:3)
The old days... (Score:1)
Read only or R/W? (Score:2)
But read/write would be tough, because then you'd have to deal with fragmentation of files and gaps after a delete. Neither tar nor *zip would like that at all....and copying over to a new archive file defeats the purpose.
Re:/dev/loop* with gzip? (Score:1)
But yet things like this *have* been done, because we *do* have compressed filesystems -- but I'm not sure exactly how they work. Perhaps they compress based on blocks rather than on files.
To answer the original question about mounting a tar.gz file, well I think the Hurd can mount a .tar file. To mount a tar.gz file would be a good deal more difficult, because you need to be able to seek() around in there. Mounting a .zip file might be a little better, because you have a table
of contents at the end of the .zip file, so you can go directly to any file. The problem then becomes seek()ing within that file.
Midnight Commander (Score:3)
Another cool thing is you can also have ftpfs, undelfs, and other interesting file systems through this MC VFS. The power is really apprent when you need a single file from a archive on an FTP site. Just connect to the FTP, browse to the dir, hit enter on the archive, browse to the file, and hit F5 to copy to the other pane (which has the proper CWD
--
Re:Addendum:/dev/loop* with gzip? (Score:1)
The User File System (Score:3)
--
doesn't userfs do this (Score:1)
i use a product on windows called ZipMagic which supports read/write operations on .ZIP files at the file-system level. it even works in a command prompt - really smart stuff.
Re:Uhhh (Score:1)
/dev/loop* with gzip? (Score:1)
Does this already exist in some form?
Addendum:/dev/loop* with gzip? (Score:1)
seek() compatable compression algorithms? (Score:1)
Then again, I may be talking out of my ass.
Re:Midnight Commander (Score:2)
Good job they called it the virtual file system then, isn't it?