gvfsd-archive write support
Submitted by Tomas Bzatek
Assigned to gvf..@..e.bugs
Link to original bug (#589617)
Description
This is a tracker bug, playground for my thoughts.
It would be nice to have full write support in gvfs's archiving backend. However this brings a lot of pain to work around technical limitations of GIO. The backend is written around the libarchive library [1] which sets further limitations for every format it supports.
Write operations over the mounted archive
We need support for basic write operations like (backend-wise) create, append, replace, write, rename/move (set_display_name), delete, make_directory (this will be tricky!). Furthermore some operations are common to Unix archive formats: make_symlink, set_attribute (chmod, chown, unix file mode, perhaps even SElinux context?).
This is getting more complicated as long as some archive formats are streaming (TAR) and some are random-access like (ZIP). Appending is usually never a problem, but deleting files might require complete archive file rewrite. We might not want to support such operations at the beginning for streaming file formats until we find a good solution (e.g. for temporary storage).
Another catch is creating empty directories as some formats only store list of files with full paths. But that's more a libarchive problem.
Also I guess we miss password protection support at the moment.
Creating new archive
User cannot easily create new/empty archives from Nautilus UI nor there's an API for that. You would need to specify new archive filename, archive format and set specific parameters (compression level, password). So I had an idea about writing a nautilus extension, which would provide a dialog for these options and at the end it would spawn the gvfsd-archive backend directly, passing the options in (apart from password, for which we need more secure way). The backend would then pull the options as a part of source mountspec, creating an empty archive. Ideally we would like Nautilus to start copy operation for the selected files, but that would involve extending the libnautilus-extension API.
Maybe some people would admit that we're reinventing file-roller - that's right, although this way we will get it all integrated in a file manager (and possibly not only limited to Nautilus) and read-write accessible to any GIO-based application.
Comments?