It is either uncompressing the file or using zgrep directly on the file contents inside the zip. If you make changes that exceed the previously saved compressed file size, new records for that file in the zip are instead created at the end, or entire sections are rewritten leaving space for the new file contents.
Again, a zip is not a filesystem, its is a entry for each file, a header and a pointer to the compressed file contents.
Quote:
Originally Posted by democrite
Thanks Kevin, will give it a try.
Concerning save times, I am aware of what modifications will cause a modification in another file. Perhaps I am misunderstanding various zlib implementations. Elsewhere for example, BBEdit can open zip archives and edit in place. Grep search and replace in the whole archive is very fast so I use that. Plus it has a dialog showing all matches per file like some editors so I can more easily browse them and see what I want to change.
Won’t mention such again unless I figure out maybe it is possible to modify some temp archive and then overwrite original. If it were possible, copy is supposed to be instantaneous on newer file systems that use snapshots. Perhaps zlib doesn’t operate as for example zip -u …
Concerning zlib, the native macOS library is supposed to be much faster, 60+ percent?, at unarchiving. Maybe Qt is already using such.
|