GNOME Bugzilla – Bug 434575
Text file position on desktop changed when file saved (regression from 2.16)
Last modified: 2008-10-20 11:03:22 UTC
Ubuntu 7.04, Gnome 2.18. When you have text file somewhere on your desktop, open it (with gedit), edit it, and save it, it's position will change. The file icon will move to the top left corner (like when creating new file). This is a regression from Gnome 2.16. This behaviour is regardless of auto-arrange setting. Steps to reproduce: 1. Create new text file on desktop. Move it eg. to the center of desktop. 2. Open with gedit, edit it and save it. 3. The text file will move from the center to the top left corner. Expected behaviour: Text file stays where the user placed it. Notes: This problem does not happen with OpenOffice.org or console-based editors (nano, mcedit). There could be problem in how gedit handles file saving. Nevertheless, this didn't happen in the previous version of Gnome.
The regression is probably due to http://bugzilla.gnome.org/show_bug.cgi?id=45953#c38 , if that's true then maybe nautilus have to wait a little before deleting metadata or maybe gedit has to change the way it saves a file...
Ubuntu 7.04, Gnome 2.18.1 This problem happen also when using gvim - version with GTK2-GNOME GUI. Metadata for the saved file are erased - position, emblem, notes. When saving in Eclipse or Netbeans metadata stays untouched.
Since there is really a loss of user data (even metadata like emblems and especially notes), I raise severity to "critical" (according to the guidelines in the severity field)...
Gedit developer has already said in http://bugs.gnome.org/436366#c1 that this has to be fixed in Nautilus...
still bugged in gnome 2.20...
*** Bug 436366 has been marked as a duplicate of this bug. ***
*** Bug 481665 has been marked as a duplicate of this bug. ***
I played a little with this bug and probably discovered the problem. Touching, modifying, truncating... whatever you do with the file, nothing forces nautilus to delete it's metadata, only if you rename or delete the file. And now the interesting part.. I checked the gedit sourcecode and discovered the way how they save documents, (simplified): A) backup enabled 1) save document to a temp file 2) move file to a backup file <-- nautilus deletes metadata 3) move temp file to the file place B) backup disabled 1) save document to a temp file 2) move file to a backup file <-- nautilus deletes metadata 3) move temp file to the file place 4) delete the backup file.. Source code says that moving, not copying the original file to backup is there for performance reason (which makes sense if the document is really big).
I wonder if the way the new gvfs library deals with metadata could solve this bug...
(In reply to comment #9) > I wonder if the way the new gvfs library deals with metadata could solve this > bug... > Well I think it will solve the problems with gvfs aware applications, e.g. new versions of gedit, gvim-gtk, gvim-gnome... But the problem described above stays, because that use case for fast and safe file saving is probably quite common also in low level utilities (vi). Right now nautilus probably deletes metadata on file delete (?file move?), maybe they should be preserved for some delay. Use cases: 1) application writes to tmp_file 2) mv file -> backup <-- nautilus is notified, start countdown 3) mv tmp_file -> file ... delay 4) nautilus countdown finished, file still there, do nothing 1) mv file -> backup / rm file <-- nautilus is notified, start countdown ... delay 2) nautilus countdown finished, file not there there, delete metadata There is also possibility to not initiate the countdown, just mark metadata with a flag "FOR DELETION" and on the next startup (or in some garbage collection thread) check existence of files and if they are not present delete appropriate metadata.
Why must Nautilus delete the metadata at all? Why not just leave it alone under move? That seems to solve this bug and address another user inconvenience - that moving a file from a backup (CD - another partition ...) will also lose the metadata. (In reply to comment #10) > (In reply to comment #9) > > I wonder if the way the new gvfs library deals with metadata could solve this > > bug... > > > > Well I think it will solve the problems with gvfs aware applications, e.g. new > versions of gedit, gvim-gtk, gvim-gnome... But the problem described above > stays, because that use case for fast and safe file saving is probably quite > common also in low level utilities (vi). > > Right now nautilus probably deletes metadata on file delete (?file move?), > maybe they should be preserved for some delay. > Use cases: > > 1) application writes to tmp_file > 2) mv file -> backup <-- nautilus is notified, start countdown > 3) mv tmp_file -> file > ... delay > 4) nautilus countdown finished, file still there, do nothing > > 1) mv file -> backup / rm file <-- nautilus is notified, start countdown > ... delay > 2) nautilus countdown finished, file not there there, delete metadata > > There is also possibility to not initiate the countdown, just mark metadata > with a flag "FOR DELETION" and on the next startup (or in some garbage > collection thread) check existence of files and if they are not present delete > appropriate metadata. >
(In reply to comment #11) > Why must Nautilus delete the metadata at all? Why not just leave it alone > under move? That seems to solve this bug and address another user > inconvenience - that moving a file from a backup (CD - another partition ...) > will also lose the metadata. > That would be imo the best solution, but unfortunately the file changes monitor that nautilus uses doesn't support a "file_renamed" event, instead a rename is seen as a "file_deleted" event next to a "file_created" event. You can see it for yourself in ttp://svn.gnome.org/viewvc/nautilus/trunk/libnautilus-private/nautilus-monitor.c?revision=13421&view=markup , see the monitor_notify_cb function... Maybe nautilus could create its own abstracted "file_renamed" event, even if the underlying monitor library didn't support it, e.g. when nautilus receives a delete event fire a timer to wait for a created event that points to the same inode hard disk data that the previous delete, then nautilus could send its own "file_renamed" event... This is just chatting because I have not investigated if this is possible... maybe a nautilus developer could comment on that...
(In reply to comment #12) > (In reply to comment #11) > > Why must Nautilus delete the metadata at all? Why not just leave it alone > > under move? That seems to solve this bug and address another user > > inconvenience - that moving a file from a backup (CD - another partition ...) > > will also lose the metadata. > > > This is correct, but only if you are moving file around the disk(s) - you intentionally execute file move. But if the clever application (gedit, vi) does this in the background for you, medata will be lost again.. ok not lost but will be on the another file, in this case the backup file. > That would be imo the best solution, but unfortunately the file changes monitor > that nautilus uses doesn't support a "file_renamed" event, instead a rename is > seen as a "file_deleted" event next to a "file_created" event. > Inotify has support for this, events IN_MOVED_FROM, IN_MOVED_TO - when the file is moved or renamed.
> > That would be imo the best solution, but unfortunately the file changes monitor > > that nautilus uses doesn't support a "file_renamed" event, instead a rename is > > seen as a "file_deleted" event next to a "file_created" event. > > > > Inotify has support for this, events IN_MOVED_FROM, IN_MOVED_TO - when the file > is moved or renamed. > That's good news, I will request for comment on nautilus list.
This has been fixed in GNOME 2.22 (Ubuntu 8.04).
*** Bug 493873 has been marked as a duplicate of this bug. ***