On 2011-04-05 at 01:13:58 [+0200], Clemens <clemens.zeidler@xxxxxxxxxxxxxx> wrote: > On Tue, 05 Apr 2011 10:13:37 +1200, Ingo Weinhold <ingo_weinhold@xxxxxx> > wrote: > > -------- Original-Nachricht -------- > > On Tue, 05 Apr 2011 09:46:23 +1200 Clemens > > <clemens.zeidler@xxxxxxxxxxxxxx> wrote: > >> On Tue, 05 Apr 2011 03:35:09 +1200, Ankur Sethi <get.me.ankur@xxxxxxxxx> > >> wrote: > >> > >> > Also, as a pre-GSoC thing, I want to write a file system that mounts > >> > ZIP files. I have some rudimentary code ready. I have a question, > >> > though: does an add-on like this already exist? > >> > >> no, but great idea! > > > > Actually, yes [1]. Though I have no idea what its current state is. > > Ah haven't knew that! > with bindfs it is possible now to mount the zip file into the current > directory. I don't see why you would want to use bindfs. You can mount a file system whereever you want anyway. > Can it also shadow the actually file somehow? I mean in that > way that you see the mounted directory with the zip file name but not the > zip file itself (name conflict)? No, and I don't think that would even be desirable. If you'd like it to work as in Windows, the MIME type should be associated with an application that mounts the zip file and opens the mount point in Tracker. If you also want to have the path look natural in navigator mode, a bit of explicit support in Tracker is needed. E.g. the mount point could be actually created in the directory (with an obvious name like "<zipname>-mounted"), but hidden by Tracker. That obviously doesn't work on read-only volumes, though and has the drawback of actually creating directories, which will be left over when not unmounted and removed. So it's probably better to leave the mount point in rootfs and rather fake navigation in Tracker. For an even more natural integration kernel support would be needed, I guess. CU, Ingo