GNOME Bugzilla – Bug 773142
"recent" view in nautilus lists files with creation dates in the far future first
Last modified: 2018-09-21 18:03:10 UTC
Steps to reproduce: 1. have some files with creation date in the far future (through a software error e.g. on a digital camera), in my case that's "Di 19 Jan 2038 04:14:07 CET" 2. open nautilus 3. click "Recent" 4. have a look at the files listed What happens: Files created *in the far future* are listed on top, although they have not been created nor accessed nor modified recently. What should happen: Be a bit more fault-tolerant. Dates which are more than 24 hours in the future (that's due to timezones) are obviously wrong, so please ignore them. Affected versions: gvfs-1.30.1-1.fc25.x86_64
Thanks for your bug report. The recent backend just shows output from GtkRecentManager. I don't think we want filter out some files in the backend just based on the timestamps. If you really see some files which were not accessed recently, this is probably GtkRecentManager bug. I don't know, how the files are sorted in Nautilus. However, if the files are just wrongly sorted, we can provide some hints for Nautilus based on timestamps from GtkRecentManager. The timestamps from GtkRecentManager should be valid... The following file contains metadata for recent files: ~/.local/share/recently-used.xbel You can see what applications added those files, timestamps, counts of registrations etc... so we can determine why those files are considered as recent. Can you provide metadata from recently-used.xbel for at least some of those problematic files?
Created attachment 339177 [details] a section of ~/.local/share/recently-used.xbel for one of the affected files (In reply to Ondrej Holy from comment #1) > The recent backend just shows output from GtkRecentManager. I don't think we > want filter out some files in the backend just based on the timestamps. If > you really see some files which were not accessed recently, this is probably > GtkRecentManager bug. It is not. I have recently opened these files and they are listed in ~/.local/share/recently-used.xbel. > The following file contains metadata for recent files: > ~/.local/share/recently-used.xbel > > You can see what applications added those files, timestamps, counts of > registrations etc... so we can determine why those files are considered as > recent. Can you provide metadata from recently-used.xbel for at least some > of those problematic files? The affected file is a JPG file with ctime: 2015-11-01, probably correct atime: 2016-10-09, correct mtime: 2038-01-19, obviously wrong (same atime and mtime are displayed in nautilus file preferences dialog). The file metadata (in file, probably EXIF) are even weirder, saying 2065-02-16.
Ok, thanks for the info. I don't think we want to ignore them. But we can set "standard::sort_order" based on the modified date from GtkRecentManager in order to fix the sort order in Nautilus...
Hmm, I've realized that setting sort_order based on modified date from GtkRecentManager would change the current behavior in a way, which I am not sure we want. GtkRecentManager has obviously info only from some GLib-based applications, so, it doesn't reflect timestamps of files. However, those files may be used by some other applications, which doesn't update GtkRecentManager. So, recent backend provides the limited list of files, which were used recently by GLib-based applications. Nautilus sort those file by mtime, so it takes into account also applications, which don't update GtkRecentManager. If we set sort_order based on modified time from GtkRecentManager, it is sorted differently than now, it doesn't take into account other applications... Maybe we can set mtime on the value from GtkRecentManager for files with mtime in future, however, I am not sure we want this. It is not our fault, that somebody has wrong timestamps. It brakes much more applications than just list of recent files... Finally, I am not sure whether mtime is the right one? Shouldn't we use ctime/atime (should be updated by move, so shouldn't be in the future). Recent files should contain also files, which were only read recently. Isn't atime more suitable in that case? Carlos, what do you think?
How about simply ignoring any file with mtime more than 24 hours in the future? 24 hours because of time zones which differ up to 24 hours and some systems handle it wrongly.
Yeah, definitely recent should use atime. We use that in Nautilus https://git.gnome.org/browse/nautilus/tree/src/nautilus-file.c#n8910 although we know atime is not that reliable... For this case about the camera, well, it's not our problem I guess, but we shouldn't fail miserably if we know the atime is wrong, polluting the whole experience. So maybe ignore them?
(In reply to Carlos Soriano from comment #6) > Yeah, definitely recent should use atime. We use that in Nautilus > https://git.gnome.org/browse/nautilus/tree/src/nautilus-file.c#n8910 Then I am not sure why the files are sorted wrongly, because the reporter has probably atime correct on his files, see Comment 2. > although we know atime is not that reliable... But atime should be updated also e.g. when moving the files in contrast with mtime, which is updated only when copying, so it should not be in the future...
What version of nautilus Christian?
I don't think we want to ignore existing files, ever.
Agree, I will replace invalid dates by modified date from GtkRecentManager if needed, but I would like to avoid it. But it seems that the atime is ok as per Comment 2, so don't know where is a problem right now. We need additional info from Christian.
(In reply to Carlos Soriano from comment #8) > What version of nautilus Christian? nautilus-3.22.1-1.fc25.x86_64 glib2-2.50.1-1.fc25.x86_64 gtk3-3.22.2-1.fc25.x86_64 gvfs-1.30.1.1-1.fc25.x86_64 (In reply to Ondrej Holy from comment #10) > Agree, I will replace invalid dates by modified date from GtkRecentManager > if needed, but I would like to avoid it. But it seems that the atime is ok > as per Comment 2, so don't know where is a problem right now. We need > additional info from Christian. What exactly? I think using atime only would be a good fix, much better than ignoring mtime as I suggested before.
(In reply to Christian Stadelmann from comment #11) > (In reply to Carlos Soriano from comment #8) > > What version of nautilus Christian? > > nautilus-3.22.1-1.fc25.x86_64 > glib2-2.50.1-1.fc25.x86_64 > gtk3-3.22.2-1.fc25.x86_64 > gvfs-1.30.1.1-1.fc25.x86_64 > > (In reply to Ondrej Holy from comment #10) > > Agree, I will replace invalid dates by modified date from GtkRecentManager > > if needed, but I would like to avoid it. But it seems that the atime is ok > > as per Comment 2, so don't know where is a problem right now. We need > > additional info from Christian. > > What exactly? I think using atime only would be a good fix, much better than > ignoring mtime as I suggested before. thing is that everywhere we use atime by default. So we don't know where the problem is in your case. Did you modified the default sorting setting in recent by chance? Can you check what's your sorting in there? I guess mtime?
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gvfs/issues/289.