GNOME Bugzilla – Bug 48085
replacing a directory overwrites (ala Macintosh) instead of merging (ala Windows)
Last modified: 2005-04-11 21:14:30 UTC
When moving a DIR with the name 'foo' to another DIR called '/test/foo' it doesn't merge it with the destination DIR, it rather deletes the content and replaces it with the source DIR. This is MacOS-like style. Maybe you should let choose the users whether using the Windows or Mac style. ------- Additional Comments From darin@bentspoon.com 2001-04-16 16:11:12 ---- gmc and many other file managers imitate the Windows style, where dropping a folder on top of an existing folder merges the contents of the two folders. We on the Nautilus team were so used to the Macintosh style, we didn't even notice this issue. This can be a really bad thing, because a user who's accustomed to the Windows way of doing things can lose a lot of files if they misunderstand the "overwrite" confirmation dialog. That's how chrisime ran into this! ------- Additional Comments From pavel@eazel.com 2001-04-25 15:19:31 ---- merging instead of overwriting during a confilct is tricky because it requires a way more complicated preflight. A merge can produce unexpected messy hirerachies to some users with a mix of new and old files. If we do this, we should probably offer the option to merge or replace in the alert that warns about the conflict. A partial solution to this could be to move replaced items to the Trash instead of nuking them on the spot. ------- Additional Comments From snickell@stanford.edu 2001-07-23 00:32:27 ---- Taking bugs previously assigned to Pavel, assigning them to myself. Will parse them out at my leisure , but many are GnomeVFS bugs we should look at for 2.0 ------- Bug moved to this database by unknown@bugzilla.gnome.org 2001-09-09 21:18 ------- The original reporter (chrisime@uni.de) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org.
Changing to "old" target milestone for all bugs laying around with no milestone set.
*** Bug 71791 has been marked as a duplicate of this bug. ***
Seth: should this be reassigned to naut-maintainers?
*** Bug 48372 has been marked as a duplicate of this bug. ***
Fixing the keyword so that others can comment.
Thanks Luis! ;) I wanted to add that I recently lost /usr/lib and /usr/bin because of this behaviour with Nautilus 2.0. It wasn't critical for me because I had nothing special installed (it just took me about two days to recompile all important software, including Gnome 2 and Nautilus 2 ironically ;)) but it could have been critical with a little bit of bad luck. So I would rather rate this as "critical" than as "enhancement". Copy and Move actions shouldn't really delete files, only overwrite (because that's what it asks for).
*** Bug 95723 has been marked as a duplicate of this bug. ***
*** Bug 95585 has been marked as a duplicate of this bug. ***
Ooops, didn't recognise the summary when I lodged my similar bug. Please see #95585 for some suggestions / discussion. I sugggest we simply move to "Windows-style" by default, as it's the safest bet, and I feel, the most understandable behaviour.
fixing qa contact.
*** Bug 97190 has been marked as a duplicate of this bug. ***
*** Bug 120946 has been marked as a duplicate of this bug. ***
*** Bug 46310 has been marked as a duplicate of this bug. ***
*** Bug 121356 has been marked as a duplicate of this bug. ***
Adding GNOMEVER2.4, GNOMEVER2.5 keywords.
*** Bug 114766 has been marked as a duplicate of this bug. ***
Has any progress been made on this topic? I am running nautilus 2.4.0 and just nuked a bunch of files because of this bug! From the comments above, this has been around for close to a year and a half and nobody done anything yet? I use gnome at home and work but I am really happy I stumbled across this at home and not work. If I had to tell my boss I just lost a load of work because of my linux filemanager it wouldn't have looked very good at all... please someone do something about this!
*** Bug 130160 has been marked as a duplicate of this bug. ***
*** Bug 134993 has been marked as a duplicate of this bug. ***
Still in 2.5, updating Version, Keywords, and Summary fields
*** Bug 136055 has been marked as a duplicate of this bug. ***
Perhaps nautilus could suggest a different name for the folder if merging is too difficult.
Created attachment 25704 [details] [review] Proposed patch to gnomevfs to implement underlying merge of dirs. The patch for nautilus will be soon.
Comment on attachment 25704 [details] [review] Proposed patch to gnomevfs to implement underlying merge of dirs. The patch for nautilus will be soon. I'm marking this 'accepted-commit after freeze' since BLOCKED_BY_FREEZE was set by alex. Alex, if we're miscommunicating on the meaning of the keyword, let me know.
Created attachment 26544 [details] [review] Updated patch, fixed bugs, added test implementation
*** Bug 140386 has been marked as a duplicate of this bug. ***
I was so upset because I lost at least one week of works, I couldn't figure out how it happened and now I see that this bug has been openned in 2001 and now I'm even more upset.. You, nautilus developpers should know that most of gnome user are not switching from mac os to linux, they're switching from windows to linux and more important from gnome 1.x to gnome 2.x in gnome 1.x the filemanager of choice was gmc who had the same behaviour as its text counterpart, mc, so copying a rep into one other has for effect to upgrade the files in there and not replace them and not REPLACING them.. now, i'm using nautilus 2.4.10 and I'm all screwed because you don't even consider people do real works here....... I'm sorry if I'm offending some who really tried to make a cool filemanager but how I'm suppose to react when even in your own paradygm you're not consistant ? how I'm suppose to react when I lost really, really, really important work because I trusted a supposed non beta version of a filemanager ? I'm so screwed, I almost want to kill myself for not having been paranoïd as usual
*** Bug 141763 has been marked as a duplicate of this bug. ***
There should probably be some kind of warning as long as the Mac style "overwrite" behavior is used, such as "WARNING - /full/path/to/target/directory and all of it's contents will be permanently deleted by this operation", so that there is no confusion as to whether it will merge or overwrite the target directory.
I don't get it : why is that so hard to just have a dialog box with the exact same behaviour than midnight commander : "Carrefull source folder and destination folder have the same name !! would you like to : replace | update | cancel is that SO f...g hard or is there something against that in the gnome zealotry handbook ? Djamé ps : is not a matter of confusion, is a matter of what the user except after 4 years of gnome 1.4 and gmc as filemanager, don't even mention those coming from windows... reps : I check, in mac os 8, the new folder has a -1 attached to it's name instead of replacing anything
Djamé is right: this needs to be addressed. The number of comments on this bug alone should speak for that. And it is a situation that leads to irreversible and possibly catastrophic data loss, not just a cosmetic defect related to whether I am used to a Mac or a Windoze environment.... That is the status of the path from 2004-04-10?
Do you know why the patch someone has already adressed has not been included into the main tree ?
*** Bug 143761 has been marked as a duplicate of this bug. ***
I still can't believe that no one care.... is there any reason to not include the patch that had been added here some years ago ? is there any reason except the whole FALSE "mac did it this way", that's not true in my powerbook with mac os 8.1 , when you copy a rep A into rep A in another directory, the new one is copied with an indice added to its name...............
... which still doesn't look very useful to me, although it's at least safer for you data. I want to be able to merge two directories in the file browser! :-) Even (command line) midnight commander does this by default.
I think severity of this bug should be critical, because this couses a loss of data Also PATCH keyword should be added to this bug. Btw, I noticed, that nautilus developers doesn't care about compability with older versions, for example like in this bug with people, that used gnome1x with gmc, another example is going to spatial mode without user-friendly way to change to previous browser behaviour.
I have lost some data too, by dragging the contents of a tarball with eclipse plugins to my eclipse installation, leaving me with a destroyed eclipse without any plugins excet the new ones. I first thought that is a file-roller regression (extract does the right thing, only DnD did it so stupidly) - until I dragged to a Rox filer window, which worked nicely. I think the rox filer should be inspected for a sane baseline implementation of intuitive behaviour. Maybe it's dialog seems a bit technical, but it makes very clear what's happening. Until Gnome 2.6 I used rox as default file manager, I was very happy when the spatial paradigm made me feel comfortable with nautilus as well, and I liked its VFS features. But this Bug is scary, so i consider switching back, until it is closed.
Seriously, don't waste your time putting bug report in this bug, the patch existed for 2 ou 3 years, and for some obscurs reason it has not been included... I checked every changelog,and I have never seen any mention of it...
Nautilus operates on files through gnome-vfs, so this is actually a bug in gnome-vfs. According to gnome-vfs changelog, this behavior has been fixed on HEAD (folders are now merged instead of overwritten). See also http://lists.gnome.org/archives/gnome-vfs-list/2004-July/msg00018.html
*** Bug 149060 has been marked as a duplicate of this bug. ***
*** Bug 150428 has been marked as a duplicate of this bug. ***
*** Bug 151414 has been marked as a duplicate of this bug. ***
*** Bug 172997 has been marked as a duplicate of this bug. ***
I can't believe that !!!!!!!!!!!!!! One year later since my bug reports, two patchs have been proposed and this fucking bug still exists ? that's the reason I never used nautilus to copy files... for me it's just a super xv... nothing more... I'm disgusting. Reallly.... it's not nautilus fault, it's the gnome-vfs one.. I'm sorry but we, user of gnome desktop, don't care about which layer is responsible........... by the way for people who want to use a normal filemanager I suggest gnome commander 1.1.6 (like mc but graphical)
If you check the bug status and comment #39, you will see that this fucking bug is actually fixed. And this since last july.
Yes I checked and it's still here look, here are my two directory structures [dse@infocom-dse tmp]$ tree test/ test/ `-- 1 |-- 2 | |-- 3 | | |-- 0.txt | | `-- 10.txt | `-- 4 | `-- kk.txt `-- 3 |-- 5 `-- 6 [dse@infocom-dse tmp]$ tree test2 test2 `-- 1 |-- 2 | |-- 3 | `-- 4 `-- 3 |-- 5 | `-- 4.txt `-- 6 |-- 1.txt `-- 3.txt copy test/1 on test/2 using nautilus [dse@infocom-dse tmp]$ tree test2 test2 `-- 1 |-- 2 | |-- 3 | | |-- 0.txt | | `-- 10.txt | `-- 4 | `-- kk.txt `-- 3 |-- 5 `-- 6 I'm using mandrake 10.1, using gnome2.6 nautilus-2.6.3-10mdk libnautilus2-2.6.3-10mdk gnome-vfs2-2.6.2-7mdk libgnome-vfs2_0-2.6.2-7mdk So I was using (I don't count gnome1.x) gnome 2.4 on a mandrake 9.2, still gnome2.4 with mandrake 10.0 and now gnome 2.6 with mandrake 10.1 I installed my distro yesterday, I applied all the updates and now this bug is still here except now there's an alert box with only two option "cancel|replace" why there's no a third one, as gmc or mc, such as "cancel|replace|merge" you're going to tell me I should have to get the last packages from gnome tree, install everything by hand and stuff... but I passed the age where I found it fun to compile everything every 2 months.... Even the slackware maintener has given up getting gnome compile by hand, he dropped out the official support for this... so tell me again, it's fixed since last july. In my mind it was fixed since 2001 when someone send a patch. Djamé ps : <french> en plus, si un type a ce bug le 9 avril 2005 comment peut on dire que c'est fixé ? moi je le vis en live, lui aussi et vous, vous balayez ça d'un revers de la main extremement méprisant. du style, "le patch est dans le cvs alors c fixé, va te faire ... connard," t'as qu'à prendre ton patch, le diff et tout recompiler toi meme. Ca sert à quoi de proposer un environnement de travail supposé simple d'emploi si par ailleurs on doit se coltiner une galére sans nom pour recompiler sans se planter tout ces putains de packages ??? j'hallucine.... et je parie que vous allez me dire "si t'es pas content, t'as qu'à utiliser windows/kde/mac os X", on fait ça gratis donc t'as rien à dire....." </french> sorry for non french readers but sometimes it's good to express his feeling in our own tong....
This bug was fixed last july in gnome-vfs, so the first version of gnome-vfs to have this bug fixed was the 2.7.4. This bug was therefore fixed in the stable release of gnome 2.8, which was out in september 2004. I just tried to follow the steps you did (with the test1 and test2 folder), and the directories are merged and not overwritten. I understand your frustration in running into this bug over and over again, but unfortunately there is now way for the gnome developers to go back and fix bugs in every version of gnome. About the french part of your answer, please note that nobody insulted you anywhere. Just out of curiosity, where is the patch that was there since 2001 ?
this bug is fixed since GNOME 2.8, if you want to rant, why not doing it on the french mandrake's bugzilla ? The bug is due to the Mandrake version beeing outdated. Nobody asks you to patch anything, just bug you distribution to get a patched package or use any other distribution with GNOME 2.8 or 2.10.
if this bug is fixed since gnome 2.8 why does bug http://bugzilla.gnome.org/show_bug.cgi?id=172997 exist ? also, it's pretty rude to say it's the distro fault because it's outdated, I'm sorry but mandrake 10.1 is less than 6 months old and I don't think a lot of mainstream distro have already gnome 2.8 or gnome 2.10.. People just cannot update their all system every 6 months.... in the matter of the patch I was refered too, I saw it on a gnome devel mailing list when i first digged everywhere to understand how I lost 1 chapter of my thesis. I looked in bugzilla and I can't even find my own report about the subject. One last word to apologize if my words seemed to be rude, it's just too anoying to lost datas, time and faith when using a desktop I really like. This is the problem with gnome, it's always like "so clooooooooooosed" from being really usable. <HS>one example ? I used nautilus 2.4 to access network files and once I get the right dir, I types my login and password as foo:bar@smb... now with this spacial stuff.. I have something to browse the network but nothing to ask the password, even if I click on a rep and then hit ctrl+L, the url of the dir didn't even appear on the field (just to get our life easier, isn't the whole interest of a desktop metaphor ?)... so one more time... so cloooooooooooose</HS>
It's because bug 172997 is not really a dup of this one. If I read it correctly it's about: a) a file can still overwrite a folder or vice versa (you can't merge the two after all) b) files/folders that get replaced during a merge are deleted instead of trashed.