GNOME Bugzilla – Bug 351290
Misplaced (copy) text with copy/paste file duplication
Last modified: 2011-03-21 19:07:21 UTC
I've searched for alot of the keywords in this bug but can't find anything simmilar. When copy/pasting a file into the same folder to duplicate the file, the place in the file name that nautilus puts the '(copy)' text is understandable but unexpected in some situations. Steps to reproduce: 1. Create empty file, name it: 'My Artist Feat. Somebody - Title.ogg' 2. Right click -> copy the file 3. Right click -> paste the file in the same folder 4. File has the name 'My Artist Feat (copy). Somebody - Title.ogg' Expected outcome: 4. File has the name 'My Artist Feat. Somebody - Title (copy).ogg' Without looking at the code, it seems to put the '(copy)' text before the first period in the file name as opposed to the last to handle files with multiple extensions (eg: file.tar.gz). It would be more natural if nautilus checked for white space in the file parts and picked the last item with white space to append the '(copy)' tag before falling back to the current behaviour.
Ubuntu bug about that: https://launchpad.net/distros/ubuntu/+source/nautilus/+bug/57218
Created attachment 72542 [details] [review] Patch for this issue
Hmmm, well, actually the problem is not as simple as I thought :) See: http://bugzilla.gnome.org/show_bug.cgi?id=306341 We would probably need something smarter, taking the mimetype into account.
This is originally from my comment in the Ubuntu bug, but I think it might be useful here. <blockquote> Windows prefixes a copy as 'Copy of $original_name' which as you say breaks ordering. If nautilus used the first part of the file (split by '.') that has no white space that would give sensible results. my song feat. artist.tar.gz -> my song feat. artist (copy).tar.gz my_file.tar.gz -> my_file (copy).tar.gz In this case ' artist' and 'my song feat' are not part of the file extension (both have whitespace), but 'tar' and 'gz' might be (no whitespace), so the sensible place to put it is before the 'tar' part. (copy) should be placed: * before the first part of the file name with no whitespace * at the end of the first part of the file name if no parts contain whitespace </blockquote>
Confirming. Oh yeah, the never-ending dot issue: We should have a reserved character for separating a filename and an extension. But life sucks. Some people distribute their stolen software using my.l33t.s0ftw4r3.tbz2, which wouldn't work correctly with your proposed pattern. Maybe we should really assume that the last '.' character is the correct hint for an extension, but we'd keep a whitelist around that more or less resembles the stupid special cases we've got in freedesktop.org.xml.in: cat freedesktop.org.xml.in | grep "[^\*]\.\(bz2\|gz\)\"" | sed 's/\([^"]*\)"\([^"]*\)"\([^"]*\)/\2/' *.abw.gz *.tar.bz2 *.tar.gz *.cpio.gz *.ps.gz *.xcf.gz *.xcf.bz2
Comment on attachment 72542 [details] [review] Patch for this issue Marking needs-work as per discussion.
Hey Manu, Could you rework your patch :) Thanks
This bug is fixed in Gnome 2.24. Please change status to fixed.
Ari, the bug doesn't seems to be fixed at all, as the patch was not commited. try to reproduce the test-case in 1st comment, and you see the bug still occur. Regards
Sorry, I mistaked bug...
I just noticed this bug in Ubuntu 9.10/Gnome 2.28.4. Regression? To reproduce: 1. Create a file 2. Copy file 3. Paste file Expected output: some.test (copy).file Observed output: some (copy).test.file
*** Bug 510280 has been marked as a duplicate of this bug. ***
This issue is still occuring under nautilus 2.30.x release (Ubuntu Lucid - Maverick).
*** Bug 625389 has been marked as a duplicate of this bug. ***
Thank you, Marcus. I also have Thunar 1.0.2 from xfce. It renames files in this manner: "some.file.txt" -> (Copy) (Paste) -> "copy of some.file.txt" with no problem. And it works with "some.file.with.many.dots.txt" file. But I like nautilus more than thunar. This bug is very old. My question is: why problem has no resolution for 4(!) years...
*** Bug 629773 has been marked as a duplicate of this bug. ***
*** Bug 644112 has been marked as a duplicate of this bug. ***
I pushed a fix for this to master that uses the same heuristic we apply while renaming. While its whitelist might not be comprehensive, and might miss some matches, at least we're consistent and we have a single place where to add double extension patterns for the future.