GNOME Bugzilla – Bug 777814
xz files extract as original name/data instead of the original name
Last modified: 2017-04-20 20:05:13 UTC
Created attachment 344370 [details] The result of double clicking on the $filename.xz file. Reddit post: https://www.reddit.com/r/gnome/comments/5qc8vf/gnomes_nautilus_untarring_when_it_should_just_be/ Uncompressing a $filename.xz file behaves like uncompressing a $filename.tar.xz file.
I'm not sure I understand the problem. What do you expect? Uncompression of your compressed file no?
It uncompresses and untars, instead of just uncompressing. Did you see the redit post?
(In reply to cooperedenday from comment #2) > It uncompresses and untars, instead of just uncompressing. Did you see the > redit post? No I didn't, please post the relevant information if any here in Bugzilla. The pourpose is to create a folder with the relevant contents, whatever that means, if it means uncompressing and untar, then that's what it does. Why do you want only uncompress and end up with a tar archive?
I will interject here: what the reporter means by “untarring” is that the decompression behavior is the same for zipped tarballs and compressed files. In this case, it is a single compressed file, but a new directory is being created for it, which is not the desired behavior.
Ahh I though we were doing something smarter for that, thanks for the clarification.
(In reply to Ernestas Kulik from comment #4) > I will interject here: what the reporter means by “untarring” is that the > decompression behavior is the same for zipped tarballs and compressed files. > In this case, it is a single compressed file, but a new directory is being > created for it, which is not the desired behavior. Yes, you are correct.
Created attachment 347187 [details] [review] uncompression: different implementation for .xz Uncompressing a $filename.xz file behaves like uncompressing a $filename.tar.xz file. This patch provides a seperate extracting implementation for .xz files.
I couldn't find a way to change the filename of the extracted folder.
Can someone review this?
(In reply to Vyas Giridhar from comment #9) > Can someone review this? Hey, I'll review today. Expect at least one/two days delay, even more if it's weekend :)
Review of attachment 347187 [details] [review]: Hey, thanks for your work :) The patch doesn't actually work, did you test it? Also the fix should be in gnome-autoar and therefore this issue is gnome-autoar rather than nautilus, but we can move there and we can fix it together, you will understand the code easily. I'll post some review details so you take it into account for fix. ::: src/nautilus-file-operations.c @@ +8435,3 @@ g_autofree guint64 *archive_compressed_sizes = NULL; gint i; + char* name; use gchar. Also use g_autofree. @@ +8480,3 @@ + name = g_file_get_uri(G_FILE (l->data)); + + if (g_str_has_suffix (name,".xz")) what about other extensions? also an .xz archive can exist with a different suffix. That's why we have the whole g_type_is_a etc (but this is managed by gnome-autoar, not us). @@ +8490,3 @@ + + extractor = autoar_extractor_new (G_FILE (l->data), + extract_job->destination_directory); You are overriding the previous extractor. This won't never work...
This did work. ~/rust-dice-0.2.0-x86_64-unknown-linux-musl.xz > ~/data for some reason. I too thought the problem was in gnome-autoar but the process flow was confusing after sometime. Will look into it.
(In reply to Carlos Soriano from comment #11) > Review of attachment 347187 [details] [review] [review]: > > Hey, thanks for your work :) > > The patch doesn't actually work, did you test it? > > Also the fix should be in gnome-autoar and therefore this issue is > gnome-autoar rather than nautilus, but we can move there and we can fix it > together, you will understand the code easily. > I'll post some review details so you take it into account for fix. I have created a patch at https://bugzilla.gnome.org/show_bug.cgi?id=777396
*** This bug has been marked as a duplicate of bug 777396 ***