How to treat uncompressed folder as compressed file?

Question

We all know about tools, 3rd-party or built in to the OS, for treating compressed files as folders. But does anyone know how to do the reverse: trick the OS into thinking that a standard folder containing some files is actually a zipped file? Solutions for Windows, Linux and Mac are sought (though I realize no single solution will work across all these platforms).

The context of the question is in getting source code version control systems like SVN, Git or Mercurial to be more efficient at storing diffs between versions of documents that are actually compressed folders (holding various XML files, a bit of metadata and a thumbnail or two), such as ODT and DOCX.

I already know about Zipdoc and similar utils that use the Git and Mercurial encode/decode hooks to transform data into and out of the repository. This is a fine solution to the problem but I found myself wanting to browse the repository containing the uncompressed folder contents of the document and individually diff the files therein.

This means the uncompressed contents must be added to the repository, not the tar'd or zipped-without-compression version of the document. This in turn means a checkout from the repository produces an uncompressed folder full of files that represent the document. Hence my original question.

The mythical product I envision would detect a folder whose name contains a "registered" extension ("docx" for example) and then "re-mounts" it as a compressed file of the same name.

Alternately, does anyone know how to exploit the Git/Mercurial encode/decode hooks to achieve this dream?

Answer 1

To solve this in a nice way, you could use a Hurd translator with nsmux - though changing your kernel is likely a big step for that :)

→ http://www.gnu.org/software/hurd/hurd/translator/nsmux.html

You might be able to adapt the tarfs translator. This would allow you to open the folders via folder,,zip.

But it would require quite some work.

(this is a nice example of a really simple usecase pointing to a rather complex problem)