GNOME Bugzilla – Bug 143385
Should monitor renamings/deletions
Last modified: 2018-04-15 00:34:25 UTC
Start Menu -> Recent Documents should show a list of recent filenames to the user, but internally it should keep the list not as filenames but as inodes (or something better for that matter). 1. Save a file from Epiphany to Desktop. 2. Open it. (File appears now in Recent Docuemnts). 3. Go to Recent Documents. 4. Open file from there. It works. 5. Move file elsewhere or rename it. 6. Go to Recent Documents. 7. Open file from there. It fails, but file exists, even though its path is different. Its inode is the same. So, why not use the inode as opposed to the filename (internally)?
Moving to libegg/recent-files.
You can't take an inode and get a filename from it. Perhaps the recent-files code should install a gnome-vfs-monitor on each folder that has recent files in it, to track renamings/deletions.
That's what I mean, something similar or better. I know you guys can do it. :)
Retitling for clarity.
Excellent, thanks.
The recent-files code used to monitor the items in the list, and when they were deleted they were removed. But then the dreaded "monitoring removable media" issue came up so I commented out the code. I guess we could probably turn it back on if we made it so it didn't monitor read-only files, but then you have the issue of things like zip disks and usb key drives that would still cause problems. It sucks.
*** Bug 155091 has been marked as a duplicate of this bug. ***
*** Bug 158274 has been marked as a duplicate of this bug. ***
Btw, the code should also look if the files are still there when the model is created (we can't monitor the files when we're not running!)
*** Bug 313438 has been marked as a duplicate of this bug. ***
*** Bug 321131 has been marked as a duplicate of this bug. ***
vincent (comment #9): this would mean a stat() storm for every local file, and a set of requests for non-local files. the model creation could really take a *long* time. the real solution would be a daemon, monitoring each file in the list and changing the state of the data/meta-data inside the list; also, the daemon would be able to offer a single model. I don't think that's going to happen with the old recent-files code - while the new recentchooser code is too low on the stack to provide this functionality by itself. I could write a high-level daemon, watching the list and the resources inside the recently used list (directely using inotify or asking gnome-vfs), and release it as a part of the session manager. But we'll have to wait until the recentchooser code hits the Gtk (that is, in the 2.16 release cycle).
gnome-panel change suggested on https://launchpad.net/distros/ubuntu/+source/gnome-panel/+bug/8949 http://librarian.launchpad.net/3025613/gnome-panel.patch "I'm not overly confident in this patch because I don't know my way around gnome-panel. It fixes the described problem for me though."
this is not the bug you're looking for: it's bug #137278 :-)
Emmanuele: should this bug still live here (libegg) or should it be moved to gtk+ (or somewhere else)?
I'm afraid BenM would shot me if I proposed a new daemon for monitoring the recent files list. :-) a similar option would consist in gnome-panel listening to the "changed" signal of its own GtkRecentManager, using gnome-vfs to check every item in the list inside a callback and eventually calling gtk_recent_manager_remove_item() if the URI doesn't point to a valid file anymore. GtkRecentManager can only do that using g_stat() on local files (which is what happens if you set the "show-local" property in a GtkRecentChooser, barring the removal from the list).
(In reply to comment #16) > I'm afraid BenM would shot me if I proposed a new daemon for monitoring the > recent files list. :-) Right :-) > a similar option would consist in gnome-panel listening to the "changed" signal > of its own GtkRecentManager, using gnome-vfs to check every item in the list > inside a callback and eventually calling gtk_recent_manager_remove_item() if > the URI doesn't point to a valid file anymore. > > GtkRecentManager can only do that using g_stat() on local files (which is what > happens if you set the "show-local" property in a GtkRecentChooser, barring the > removal from the list). Well... This is not only about gnome-panel, but really about everything: let's say I download a video from internet. It automatically opens in totem. I like the video, but the name is 12313123.mov and I rename it to my-lovely-video.mov. The file should still appear in totem's recent documents list.
until gnome-vfs of something similar can be lowered down the stack and gtk+ can use it, GtkRecentManager won't be able to reliably (and efficiently) monitor local files. re-assigning to the right component and lowering priority.
*** Bug 412664 has been marked as a duplicate of this bug. ***
Opening Totem (xine) and clicking movie tab shows up many now deleted or renamed video's under old name.
Can't we have a tab under edit preferences to clear/update this recently played list.
An idea for the implementation: instead of constantly monitoring files (daemon, stats, etc), the recent list could be updated only when any file is renamed/moved/deleted/. For example, when a file is renamed, the old name will be searched in the recent list. If the old name is found in the list, then the name in the list will be changed. In this way, we don't need to monitor all files in recent list. Only any renamed/moved/deleted file (or directory) will be searched (by a low-priority process) in the recent list, and renamed/re-path-ed/removed from the list if found. Useful?
(In reply to comment #22) > An idea for the implementation: instead of constantly monitoring files (daemon, > stats, etc), the recent list could be updated only when any file is > renamed/moved/deleted/. > > For example, when a file is renamed, the old name will be searched in the > recent list. If the old name is found in the list, then the name in the list > will be changed. > > In this way, we don't need to monitor all files in recent list. Only any > renamed/moved/deleted file (or directory) will be searched (by a low-priority > process) in the recent list, and renamed/re-path-ed/removed from the list if > found. > > Useful? How do you detect renames/deletions without monitor the files?!
Maybe you can say to the operating system: Please, call to my_function() if you rename/move/delete any file. Perhaps that implies more overloading than the monitoring? If so, just discard my idea ;-)
(In reply to comment #24) > Maybe you can say to the operating system: Please, call to my_function() if you > rename/move/delete any file. That's exactly what gio file monitoring does. > Perhaps that implies more overloading than the monitoring? If so, just discard > my idea ;-)
(In reply to comment #25) > (In reply to comment #24) > > Maybe you can say to the operating system: Please, call to my_function() if you > > rename/move/delete any file. > > That's exactly what gio file monitoring does. Oops. You said "any file". No, I don't think that's quite possible right now. > > Perhaps that implies more overloading than the monitoring? If so, just discard > > my idea ;-) >
Ok. If not possible, just discard the proposed idea of the o.s. callback for any file change. I thought on that because, for example, if a file is renamed in a shell ("mv f1.txt f2.txt"), the o.s. will know both the old name and the new name, so the recent list will be updated correctly with the new name. But with a monitor, you'll probably discover that the old name doesn't exist any more (the file has disappeared), but you won't know that the file has been renamed (nor the new name). So you will only be able to remove the item from the recent list. Anyway, the problem of renamed/moved/deleted files in recent list will be less important if we implement a proposal I've done for the recent list: Bug #548069 Map the recent file list to a directory of links With that implementation, the recent list items will be links (symlinks) to the original (opened) files. Since, in the unix tradition, broken links (links that refer to non existant files) make sense (in fact, in the command line, they are colored in red), then broken links in the recent list will also make sense. Of course, if a monitoring engine would be able to intelligently keep the recent list updated for files that have been renamed/moved/deleted, that would be perfect. But, if perfection is not reached, the problem of haven non-updated links won't be very important. Since broken links make sense in unix.
*** Bug 378281 has been marked as a duplicate of this bug. ***
*** Bug 603994 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
As announced a while ago, we are migrating to gitlab, and bugs that haven't seen activity in the last year or so will be not be migrated, but closed out in bugzilla. If this bug is still relevant to you, you can open a new issue describing the symptoms and how to reproduce it with gtk 3.22.x or master in gitlab: https://gitlab.gnome.org/GNOME/gtk/issues/new