Fuse-zip

[Bridget Peral]

tocopy files and folders from a zip file mounted as a folder using fuse-zip to another fuse-zip folder. There are 1,524 files in total inside the Camera/ folder. After some time, my PC gets hot, fan spins faster and I am given this error on the top of my screen

The odd thing is, when I set the destination to home/username/Documents -- local folder, the entire copying process completed without errors or interruptions. I have 16 GB of RAM. What and why is there a problem when copying inside a fuse-zip folder?

Bottom line, fuse-zip can use/need huge amounts of memory in some situations and if your RAM memory is limited or even average then doing huge/massive file operation such as copying is not recommended and might not work due to it exhausting system memory.

If, however, you must do it your way anyway ... Then, copy some files while monitoring your memory usage and when your memory gets near to full, stop copying and unmount the target fuse-zip mount wait for it to finish processing, then mount it again to copy another batch of files and so on ... However, I don't know of a tool that will let you do that automatically ... So, I wrote this bash function(fault proofing is minimal and it's meant to be a template):

Hello, I swapped fuse-zip for fuse-archive because it's quite a bit faster than other fuse-mounting programmes. But when I use it to mount a zip from vifm, it takes a bit longer to show the mounted files:

It might be that fuse-archive lazy-loads files, which would explain both faster mount and longer file loading. I think I looked at its code years ago and it lacked caching (at least looked up file by path on every access, which was really slow for large archives). Things might have changed since then. Either way, Vifm works with both mounters the same.

Hello, I am experiencing a problem with copying large file sizes from my galaxy s21 to a fuse-zip mount point (Bitbucket). I have a zip file which I mounted with a empty folder in user space which gives me access to all the files in read-write. I connected my galaxy s21 with usb, then copied a file that is 16 GB into the fuse-zip folder, and when reaching 4 GB limit, the copy operation failed. Please see the following screenshots below:

It seems 64-bit file access is a Android extension of MTP. gvfs mtp backend explicitly checks whenever it supports android extensions before failing on accessing files higher than the vanilla MTP limit. I wonder if it fails to detect as an android device for GVFS. libmtp uses a different way to detect support for reading above 4 GB, maybe GVFS could adopt that.

(Just a guess, I have never contributed to gvfs or looked into mtp before. I assuming it is MTP because it looks like you are copying from your android device via MTP and it was an reading error not writing.)

Also, I mounted my galaxy s21 with a webdav server pro app from the olive tree ( =com.theolivetree.webdavserverpro) and then connected my phone in ubuntu as webdav connection, copying the same 16 GB file from webdav android to fuse-zip results in the same fail copy operation. So it seems that there is a problem with gvfs for large >4GB files.

As you can see it invokes fuse-zip to mount archive as a directory. FUSE is probably present and working (assuming that you use GNU/Linux, but there is also OS X analogue; Windows seems to had one too, but it's probably incompatible with FUSE mounters out there), so all you need is to install fuse-zip.

use-zip is a FUSE file system to navigate, extract, create and modify ZIP and ZIP64 archives based on libzip implemented in C++. With fuse-zip you really can work with ZIP archives as real directories. Unlike KIO or Gnome VFS, it can be used in any application without modifications.

If you 'install' that application and drag its icon also to the Finder toolbar, (in macOS this was made slightly more complicated: hold Cmd and then drag the app to the toolbar until you see a plus sign) you have a convenient, low-cost solution, that allows you to look inside the archives, extract single files as needed and even manipulate the contents without a full decompression (and/or re-compression). Although that last feature seems to be judged as not that stable by the developer, as it's turned off by default: without setting any preferences it defaults to 'mount' archives read-only.

To solve the issue with double-click resulting in an undesired action (full decompression), you then have to choose from one of the options listed here your favourite method. Then right-click on a zip-file and choose "Get Info". Set your desired action accordingly under the heading "Open With".

We have been running our browsable coderepository code.woboq.org for quite a while now.Adding more and more projects, at some point we noticed that we were getting low on disk space.In this blog post, we explain how we saved huge amount of disk space holding our static HTML files.

Firstsome background on how we do things on the server: The subdirectories (like /linux)are mounted file system images (loop mount).This allowseasy upload from a powerful machine where we generatethe HTML, and reference files for the code browser.There is a huge amount of small files so usinga file system image makes uploading easier and also allows us toupdate code.woboq.org in a more transactional way: You can just remount the image!

To improve our (lack of) disk space situation,we thought about how we could use compression.The current uncompressed size of code.woboq.org was about 25 GBon an ext4 file system images. A natural ideawould be to switch to Btrfs images (which can do compression).However our kernel does not support Btrfs.

We looked at fuse-zip first,a way to mount ZIP archives as a directory.However, we found out after some time that the fuse-zipversion in our Linux distro does not support ZIP64 yet.This means the huge (in terms of inode count) directories that the code browsergenerator can create were not supported.

So if we would have needed to compile fuse-zip ourselves (in a more current version)anyway, we thought: Maybe there is an even better way than mounting a ZIP archive. After all it was neverthe intention of the ZIP format to have people use it as a file system.

Turns out there is a better way!We remembered that a lot of embedded devices and Linux Live CDsalso need to save space. They often use Squashfs for that.So that's what we decided to use too.Our kernel does not support Squashfs so we are using the FUSEmodule squashfuseand so far are quite happy with it.

Regarding the performance, we have not found any drawbacks yet.Possibly Squashfs is even faster since less data needsto be read from the slow hard drive, making the slowdownthat the decompression must cause irrelevant.

If you like this blog and want to read similar articles, consider subscribing via our RSS feed (Via Google Feedburner, Privacy Policy),by e-mail (Via Google Feedburner, Privacy Policy)or follow us on twitteror add us on G+.

Questions on Server Fault must be about managing information technology systems in a business environment. Home and end-user computing questions may be asked on Super User, and questions about development, testing and development tools may be asked on Stack Overflow.

While there are a variety of programs which can open files from inside a zip, they generally do this by extracting the file and saving it in a temporary location (on memory or disk). The zip file itself is never changed.

Changing the contents of the file would require the contents of the zip to be extracted, altered, then re-compressed--automating the process you refer to. I'm not aware of any Mac OS editors which do this automation.

The exception is the case where you actually mount the archive as a filesystem, which I believe can be done using FUSE with the fuse-zip extension (see MacFuse for a GUI). But this might be overkill for your needs.

PS: It does in the background extract the file to a temp location and re-compresses the archive on change, but from user's perspective, it does basically allow opening files from zip archives and changing them.

BBEdit 11 and later can now directly open and edit zip files, including files that have different endings, like pptx or docx. You can also add the OOXML Tools add-in to the Chrome browser to do simple edits to zipped files

I'm wondering whether there is any way to include images that are in an archive. My reason for this is that I have a project where a very large number of sprites are used (each in different versions). Having several thousand image files is a bit of a hassle as, e.g., a copy of the project within the file system takes a long time. It would be much more convenient to have all images packaged together (potentially one package per version).

Edit: I accepted Sergei's answer as that indeed is an option. Still am curious as to whether this could be done in tex (or maybe luatex) without having to rely on the operating system. Mounting a zip does require some setup and can be a bit of a hassle if different users on different machine work on a document.

You can't directly include graphics from an archive file, but you can mount an archive into a directory using, for example fuse-zip and include graphics from the mounted directory. For example, the following works for me in Debian linux:

3a8082e126