After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 589617 - gvfsd-archive write support
gvfsd-archive write support
Status: RESOLVED OBSOLETE
Product: gvfs
Classification: Core
Component: archive backend
unspecified
Other Linux
: Normal enhancement
: ---
Assigned To: gvfs-maint
gvfs-maint
: 651885 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-07-24 14:58 UTC by Tomas Bzatek
Modified: 2018-09-21 16:50 UTC
See Also:
GNOME target: ---
GNOME version: Unversioned Enhancement



Description Tomas Bzatek 2009-07-24 14:58:58 UTC
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?

[1] http://code.google.com/p/libarchive/
Comment 1 Matthias Clasen 2009-07-25 02:02:06 UTC
Pssst, you are reinventing file-roller :-)
Comment 2 Tomas Bzatek 2009-08-03 09:19:33 UTC
Not completely related, but another great idea was posted on gtk-devel-list and we might benefit from it: http://mail.gnome.org/archives/gtk-devel-list/2009-July/msg00143.html
Comment 3 Tomas Bzatek 2011-06-06 11:13:00 UTC
*** Bug 651885 has been marked as a duplicate of this bug. ***
Comment 4 Nelson Benitez 2011-12-17 13:16:58 UTC
FWIW, and just in case you are not aware of it, nautilus already have integration with file-roller for archiver support, you can drag any set of files and drop it over any archiver file supported by file-roller and the files will be added to the archiver (it calls file-roller in the background).

But what is still lacking, imo, is a way to create a new empty archiver file where we can later add files by Dnd as said before. But that can easily be done as template files just like the "New Document" template file.

The downside of this support is its poor discoverability by the user, in that regard the file-roller nautilus extension is better as it shows on the right click menu some actions to archive the selected files in a new archiver file.

Also, file-roller already exports d-bus api to create/extract archiver files, see bug 627732 for details.

With this comment I just wanted to summarize what I know about Nautilus support of archive files in case it can avoid any duplicate effort.
Comment 5 Ondrej Holy 2013-06-25 12:38:48 UTC
There is an implementation of write support: 
https://github.com/ondrejholy/gvfs/tree/gvfsbackendarchive

However caching must be implemented before possible merging, because every modification of an archive is sequential (the whole archive must be read, new temporary archive must be write with required changes and finally the original archive must be replaced by the temporary).
Comment 6 GNOME Infrastructure Team 2018-09-21 16:50:54 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/103.