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 306341 - Nautilus creates a tarfile with wrong extension.
Nautilus creates a tarfile with wrong extension.
Status: RESOLVED FIXED
Product: nautilus
Classification: Core
Component: File and Folder Operations
2.11.x
Other Linux
: High minor
: ---
Assigned To: Nautilus Maintainers
Nautilus Maintainers
: 46455 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-06-03 04:51 UTC by dinoop.thomas
Modified: 2006-09-14 19:58 UTC
See Also:
GNOME target: ---
GNOME version: 2.9/2.10


Attachments
Attached patch fixes the bug (932 bytes, patch)
2005-06-03 14:03 UTC, dinoop.thomas
none Details | Review

Description dinoop.thomas 2005-06-03 04:51:22 UTC
1.Browse to a folder containing a tar.gz archive (E.g. mydata.tar.gz) 
2.Create a duplicate of this archive file. (Select the archive file;
Edit -> Duplicate)

Observation and bug -> Nautilus creates a duplicate file named
"mydata.tar (copy).gz".

When a user tries to extract from this file, file-roller does not
completely restore the folder contents, since the intermediate archive
file generated is named "mydata.tar (copy).gz"

Expected -> The duplicate file must probably be named as "mydata
(copy).tar.gz" [The word "copy" preceding the ".tar" extension
Comment 1 dinoop.thomas 2005-06-03 04:56:24 UTC
I'll be looking into this issue and giving a patch, Thanks.
Comment 2 dinoop.thomas 2005-06-03 14:03:26 UTC
Created attachment 47189 [details] [review]
Attached patch fixes the bug

The patch changes strrchr() function in parse_previous_duplicate_name to
strchr() so that the '(copy)' gets added before the first '.' in the file name
when a duplicate copy is created.
Comment 3 Christian Neumair 2005-06-03 15:27:51 UTC
Thanks for your bug report and your patch!
It was indeed decided that it is sane to assume that the file extension begins
after the first dot in a filename.
Comment 4 Christian Neumair 2005-06-03 19:25:36 UTC
Also see bug 302044.
Comment 5 Alexander Larsson 2005-06-28 12:58:05 UTC
commited.
Comment 6 Christian Neumair 2005-07-10 19:58:50 UTC
*** Bug 46455 has been marked as a duplicate of this bug. ***
Comment 7 Marcus Sundman 2006-09-14 19:58:16 UTC
> It was indeed decided that it is sane to assume that the file
> extension begins after the first dot in a filename.

I don't know who decided what, but such a decision would not by any stretch of the imagination be sane. There are extremely many files named "My.First.Song.mp3" or somesuch, often just to not have problems with various systems that have issues with spaces (e.g. "%20" and "+" in URLs).

Since file extension databases can be outdated, or simply wrong, the only even remotely sane way of handling the issue would be to put the "copy" thing first, e.g ."Copy of My.First.Song.mp3". This breaks ordering (well, kinda, unless you indeed want all copies to be grouped together when ordering), but that's the least evil thing to do unless you want to ask the user all the time.