Short version: I think that libarchive is failing to clear it's internal errno properly and improper error statuses are filtering through the code and making successful operations appear to fail. Long version: After upgrading to GNOME 2.26 I noticed that the new "Archive Mounter" wouldn't open any .zip files that I had. .tar.gz files seemed to work, but .zip's didn't. After a lot of debugging, I think I've basically tracked it back to libarchive giving an improper status. Turning on debug prints for gvfs and running /usr/libexec/gvfsd-archive file=...zip through gdb eventually shows it reading the zip file and successfully processing the contents and then discovering a previously unknown failure and aborting the mount during gvfs_archive_pop_job(). Tracking this with debug prints and gdb shows that gvfs gets out of create_file_tree() (gvfsbackendarchive.c) sucessfully with a result of ARCHIVE_EOF, but the data tells a different story: (gdb) p *archive $8 = {archive = 0x1216cb0, file = 0x1206c80, stream = 0x12080c0, job = 0x12030c0, error = 0x0, data = "PK\003\004..."...} (gdb) p *archive->archive $10 = {magic = 14594245, state = 16, vtable = 0x7f7982e7fb40, archive_format = 327680, archive_format_name = 0x12177b8 "ZIP 1.0 (uncompressed)", compression_code = 0, compression_name = 0x7f7982c75e47 "none", file_position = 8564739, raw_position = 8565393, archive_error_number = -1, error = 0x0, error_string = {s = 0x1215860 "Using external unxz program for xz decompression", length = 0, buffer_length = 64} So, archive_read_next_header() returned ARCHIVE_EOF, but archive->archive->archive_error_number is -1 and archive->archive->error_string is talking about unxz, but the length of that string is 0. Looking in libarchive, we find that archive_read_next_header2() (archive_read.c:379), which is called by archive_read_next_header(), attempts to clear the library error status with a call to archive_clear_error(), but that function only clears the error string (by setting it's length to 0) and the error pointer itself. It misses the archive_error_number variable that gvfs is consuming. Thus, gvfs thinks there's an error when there isn't one and it aborts the open/mount of the zip. Simply clearing the archive_error_number field in archive_clear_error() appears to restore functionality for .zip files (hmm.. .iso files seem similarly effected). Upstream doesn't seem to have hit this. Reproducible: Always Steps to Reproduce: 1. /usr/libexec/gvfsd-archive file=<path_to_zip_file> Actual Results: Program exits without mounting the zip file. Expected Results: No program exit (it should stay running) and zip file mounted under ~/.gvfs
Created attachment 207261 [details, diff] Clear archive_error_number in archive_clear_error() archive_clear_error() doesn't appear to be clearing all of the internally stored error fields. Since archive_error_number is exposed via the archive_errno() interface (and gvfs, at least, is consuming this data), this could lead to false failures.
Was this submitted upstream yet?
(In reply to comment #2) > Was this submitted upstream yet? Not yet. I thought I'd start here first. :-)
Please start upstream instead, it's easier if Tim just releases a new version.
Check the alpha for the 2.8 version please.
(In reply to comment #5) > Check the alpha for the 2.8 version please. hmm... It's not quite fixed. 2.7.902a and, surprisingly, 2.7.1 both appear to work properly, but they're not truly fixed. The change from lzma-utils to xz-utils between 2.7.0 and >2.7.0 causes libarchive to start working (with USE=lzma) because the probe for xz support stops failing and leaving the archive_errno set to a non-zero value. However, with USE=-lzma then either of 2.7.1 or 2.7.902a will still fail in the same old way. Thinking on this issue since I originally filed it, I wonder if this (not clearing archive_errno) is really a bug with libarchive or a bug in how gvfs is using libarchive. gvfs is essentially checking libarchive's errno unconditionally and if it's non-zero, then gvfs declares the operation an error. I'm uncertain whether or not libarchive wants to be used this way. In glibc, errno is undefined if the library call returns success. glibc is very specific about this. "Its value is significant only when the return value of the call indicated an error", says "man errno". libarchive is not as firm. libarchive says that on receipt of an ARCHIVE_FATAL, ARCHIVE_WARN or ARCHIVE_RETRY return status, that errno is available. It doesn't mention what happens on ARCHIVE_OK or ARCHIVE_EOF, nor does it say that it's improper to look at the archive_errno after one of those return statuses. So, I think we may need to bring this to the attention of both gnome and libarchive upstream devs (or hash it out with the gnome team here, perhaps?) and get some guidance and see how the whole thing should fit together. Regardless, something's still broken.
It's still a problemf or upstrema.
