When replacing a file the Date Modified does not update. The user must exit and re-enter the folder for the correct Date Modified to be shown. Note this bug has been around in some form for at least 2 years and probably longer. I believe it started to occur between Thunar's release on EL5 (~Thunar-1.0.2-2) and EL6 (~Thunar-1.3.0-4), although my first record of this bug is January 2013 (EL6.3). I have marked this bug as "major" because the display of correct files dates is crucial when transferring data between folders (e.g. replacing backups).
There exists another related issue; Sometimes even when exiting and re-entering the folder the date modified will remain the same (e.g. when browsing an external drive). The user must open a new instance of Thunar for the correct modified date to be displayed.
The same problem happens with the file size https://bugzilla.xfce.org/show_bug.cgi?id=11468 and that's even more dangerous than file date.
I haven't found yet how to properly fix this bug. A temporary and ugly patch is here: https://gist.github.com/LinuxMatt/640ed8b1dda47794b458
Meanwhile waiting for a fix to come out, I've shifted to PCManFM (and Nemo because PCManFM is lighter but has some bugs as well and once in a while it crashes on smb://).
*** Bug 10504 has been marked as a duplicate of this bug. ***
*** Bug 11468 has been marked as a duplicate of this bug. ***
Created attachment 5903 Assume file changed while in cache This might be a performance penalty, but this seems to refresh the file info on copy.
Tested, works.
Pushed to master: http://git.xfce.org/xfce/thunar/commit/?id=cc8d1331e305f2af5842607d885eb96608b8fce7
Created attachment 6089 Fix-updating-file-info-for-moved-files-bug-11008.patch The previous solution in attachment #5903 causes crashes because of freeing and accessing file info in parallel threads, spawned by thunar jobs. An easy way to reproduce such a crash, or at least to create critical errors, is to drag & drop move lots of files into a subfolder one by one. This needs to be reverted and replaced by a proper fix. The attached patch fixes this for me.
GFileMonitor Test application: Download and compile https://gist.githubusercontent.com/dmatveev/2295597/raw/973da911a653550d762cffea20153db9ca52400b/gistfile1.c gcc -o gfilemonitor gistfile1.c $(pkg-config --cflags glib-2.0) $(pkg-config --libs glib-2.0) $(pkg-config --libs gio-2.0) Now for a file or folder to watch, execute it with the path as argument: (1) gfilemonitor test/first (2) gfilemonitor test/second touch test/first/a test/first/b (1) Received event CREATED: (code 3), first file "a", second file "--" Received event ATTRIBUTE_CHANGED: (code 4), first file "a", second file "--" Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--" Received event CREATED: (code 3), first file "b", second file "--" Received event ATTRIBUTE_CHANGED: (code 4), first file "b", second file "--" Received event CHANGES_DONE_HINT: (code 1), first file "b", second file "--" Test case 1: Move a file to another folder mv test/first/a to test/second/a (1) Received event DELETED: (code 2), first file "a", second file "--" (2) Received event CREATED: (code 3), first file "a", second file "--" Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--" Test case 2: Move a file in the same folder Recreate test/first/a: touch test/first/a mv test/first/a test/first/b (1) Received event MOVED: (code 7), first file "a", second file "b" (2) -- Test case 3: Copy a file to another folder (does not exist there) cp test/first/a test/second/a (1) -- (2) Received event CREATED: (code 3), first file "a", second file "--" Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--" Test case 4: Move a file using thunar cut & paste (target file does not exist) (1) Received event DELETED: (code 2), first file "a", second file "--" (2) Received event CREATED: (code 3), first file "a", second file "--" Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--" Test case 5: Move a file using thunar cut & paste (target file exists) (1) Received event DELETED: (code 2), first file "a", second file "--" (2) Received event CREATED: (code 3), first file ".goutputstream-97BSVX", second file "--" Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--" Received event MOVED: (code 7), first file ".goutputstream-97BSVX", second file "a" Received event CHANGES_DONE_HINT: (code 1), first file "a", second file "--" Received event ATTRIBUTE_CHANGED: (code 4), first file "a", second file "--"
Using both a file monitor and a dir monitor on both directories, and additionally a file monitor and a dir monitor on the moved file, it looks like everything is ok with gio. Just for the record, if SEND_MOVED was not used, the following gio bug could have been triggered, but thunar uses SEND_MOVED in 1.6.6: https://bugzilla.gnome.org/show_bug.cgi?id=742849
*** Bug 11734 has been marked as a duplicate of this bug. ***
Created attachment 6118 Always-reload-info-for-files-that-might-have-been-changed-by-jobs.patch This patch obsoletes the previous patches (though parts of my previous patch might still be correct to apply) and fixes the update issues for me.
Created attachment 6119 Fix-updating-file-info-for-moved-files-bug-11008.patch This patch is still necessary for updates caused by move operations. I have corrected one check so it should work properly now.
There is still the problem that the folder monitor does not receive any events for the following scenario: 1) touch x 2) mkdir test 3) open test in thunar 4) mv x test test is not updated to reflect the move. If you open another window with the source directory before 4), then the changes will propagate and the views will update correctly.
It seems the issues with filemonitor events not being triggered have to do with the shortcut side pane. Turning the sidepane off (but also switching to tree-view sidepane probably) will make the test cases work as expected. However, these new findings may not completely invalidate the previous patches.
Created attachment 6126 0001-Add-function-to-reload-parent-file-of-a-file.patch Another patchset for reloading issues (1/3)
Created attachment 6127 0002-Rework-thunar_file_monitor-to-properly-register-move.patch Another patchset for reloading issues (2/3)
Created attachment 6128 0003-Refactor-code-for-moving-thumbnail-cache-file-on-ren.patch Another patchset for reloading issues (3/3)
Created attachment 6129 0004-Reload-parent-folder-of-changed-file.patch Fix update of parent folder in folder-monitor.c
Comment on attachment 6129 0004-Reload-parent-folder-of-changed-file.patch This patch is bad and should not be applied.
Unfortunately, there is another test case that doesn't work: 1) echo 2000 > x; mkdir test; touch test/x 2) open thunar 3) cut x 4) change into test 5) select x 6) paste There are delete events for the source folder, but the destination folder does not receive any events. Also, reloading the folder does not help.
*** Bug 11707 has been marked as a duplicate of this bug. ***
Created attachment 6132 Fix-updating-file-info-for-moved-files-bug-11008.patch Update patch to protect against unreadable files.
(In reply to Harald Judt from comment #23) > Unfortunately, there is another test case that doesn't work: > > 1) echo 2000 > x; mkdir test; touch test/x > 2) open thunar > 3) cut x > 4) change into test > 5) select x > 6) paste > > There are delete events for the source folder, but the destination folder > does not receive any events. Also, reloading the folder does not help. Note that thunar-job.c signal-emits new_files for the new_files closure, but the standard-view does not call thunar_standard_view_new_files. There is something else strange here: After step 6), the following happens: thunar_file_monitor: event_path=/home/user/x, other_path=/home/user/(null)/x, file=user, event_type=7 What happened to test (other_path=...(null))???
Further observations: 1) File moves via cut & paste into the same window do not receive the new_files signals, thus thunar_standard_view_new_files will NOT be called. Therefore, file info for an existing target file will not be updated. If the target file does not exist, the file will of course have the correct attributes, but after the folder reload thunar_file_monitor will be invoked with the target folder being (null) in other_path (e.g. /home/user/(null)/x). 2) File moves via cut & paste using two windows, one serving as source and one as target, do receive the new_files signals, thus thunar_standard_view_new_files will be called in the target window and the info for the target file will be updated for an existing file. In the source window, there will be no MOVED event emitted for the source window, only two DELETEs, one logged by thunar_folder_monitor and one by thunar_file_monitor. If the target file does not exist, the new target file will have the correct attributes in the target window, but as in 1), after folder reload thunar_file_monitor will be invoked in the target window with the target folder being (null) in other_path (e.g. /home/user/(null)/x). 3) With copy & paste there are no such bugs, the new_files signals will be received and the files reloaded properly. With cut & paste, thunar_clipboard_manager_clear_callback gets called before the end of tsv_action_paste, while with copy & paste, it gets called on window close. In both cases, it releases all pending files.
thunar_file_monitor: event_path=/home/user/x, other_path=/home/user/(null)/x, file=user, event_type=7 This happens even without any of the patches, so it is not caused by them.
*** Bug 11763 has been marked as a duplicate of this bug. ***
I stand corrected, it also happens with copy&paste. But I got a bit further to a solution: Indeed, this seems to be a timing problem. http://git.xfce.org/xfce/thunar/tree/thunar/thunar-job.c#n573 Adding sleep (1); before this line solves the problem for me: -- /* emit the "new-files" signal */ sleep (1); exo_job_emit (EXO_JOB (job), job_signals[NEW_FILES], 0, file_list); -- The move event is also properly triggered, with no "(null)" in other_path.
Interestingly, with the sleep(1) https://bugzilla.xfce.org/attachment.cgi?id=6118 is rendered unnecessary, and the standard view is updated properly.
An additional test case for verification (though it does not bring any new revelations): 1) Generate lots of files: for i in $(seq 1 1000); do echo "$i" > "$i".txt; done 2) Cut files using thunar Edit->Cut 3) Create a new directory test 4) Change dir to test in thunar 5) Paste files in thunar Behold the many object_unref errors: (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-WARNING **: invalid uninstantiatable type '(null)' in cast to 'GObject' (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-WARNING **: invalid unclassed pointer in cast to 'GObject' (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-WARNING **: invalid uninstantiatable type '<invalid>' in cast to 'GObject' (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed (thunar:31965): GLib-GObject-CRITICAL **: g_object_unref: assertion 'G_IS_OBJECT (object)' failed
The final piece of the puzzle: The new-files closure gets invalidated by thunar_standard_view_selection_changed while still being in use. Because of this, the signals sent by the job cannot be received and get lost. This also causes the g_object_ref/unref errors in comment #32. Treatment of the new-files closure needs to be changed, maybe tsv can be extended to allow multiple closures so that all running jobs can finally send their list of changed files. The new-files closure is used by tsv_selection_changed to select new files after a job has finished (e.g. after file move select the moved files in the target folder).
A better solution than reloading the file info for all files in the new-files closure is to move/copy the file info in thunar-transfer-job.c for cached files only.
Created attachment 6180 reload-files-changed-by-jobs-in-an-idle-loop.patch This builds on top of the other patches and obsoletes attachment #6118 . With this, complicated changes to the closures system are unnecessary and all files will get scheduled for reload in idle before the new-files signal is emitted.
A temporary repository with all necessary patches based on up-to-date master is here: http://git.xfce.org/users/hjudt/thunar/log/?h=fix-bug-11008
*** Bug 9340 has been marked as a duplicate of this bug. ***
*** Bug 9446 has been marked as a duplicate of this bug. ***
*** Bug 11829 has been marked as a duplicate of this bug. ***
The patches have been merged to master. So far, all tests have turned up nothing bad, and the reload seems working fine.
BTW: What has not been fixed yet is the issue described in bug #9245. It's a minor issue though and hitting F5 / reload is a usable workaround.
*** Bug 10955 has been marked as a duplicate of this bug. ***
(In reply to Harald Judt from comment #40) > The patches have been merged to master. So far, all tests have turned up > nothing bad, and the reload seems working fine. Not sure if this is related to this patch set, but scrolling up in a directory (with detailed view) when Thunar is reloading the file list scrolls down automatically, to the position before the reloading started.
This recent patch causes Thunar to crash when you have two windows or tabs open in the same directory and then delete a file inside of that directory. Here is a backtrace for it: Program received signal SIGSEGV, Segmentation fault. 0x00000000004367da in thunar_file_info_reload (file=file@entry=0xdd2210, cancellable=cancellable@entry=0x0) at thunar-file.c:976 976 if (strcmp (file->basename, "kmsg") == 0 (gdb) bt #0 0x00000000004367da in thunar_file_info_reload (file=file@entry=0xdd2210, cancellable=cancellable@entry=0x0) at thunar-file.c:976 #1 0x0000000000436c41 in thunar_file_load (file=file@entry=0xdd2210, error=error@entry=0x0, cancellable=0x0) at thunar-file.c:1178 #2 0x000000000043893b in thunar_file_get (gfile=gfile@entry=0x0, error=error@entry=0x0) at thunar-file.c:1237 #3 0x0000000000438c92 in thunar_file_monitor (monitor=<optimized out>, event_path=0xe178e0, other_path=0x0, event_type=<optimized out>, user_data=<optimized out>) at thunar-file.c:802 #4 0x00007fffefdef04c in ffi_call_unix64 () from /usr/lib64/libffi.so.6 #5 0x00007fffefdeea1a in ffi_call () from /usr/lib64/libffi.so.6 #6 0x00007ffff4e4b535 in g_cclosure_marshal_generic_va (closure=0xc275d0, return_value=0x0, instance=0xbae380, args_list=<optimized out>, marshal_data=0x0, n_params=3, param_types=0xc24170) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gclosure.c:1594 #7 0x00007ffff4e4aac7 in _g_closure_invoke_va (closure=closure@entry=0xc275d0, return_value=return_value@entry=0x0, instance=instance@entry=0xbae380, args=args@entry=0x7fffffffc2c8, n_params=3, param_types=0xc24170) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gclosure.c:864 #8 0x00007ffff4e63988 in g_signal_emit_valist (instance=0xbae380, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7fffffffc2c8) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gsignal.c:3216 #9 0x00007ffff4e645da in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=detail@entry=0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gobject/gsignal.c:3363 #10 0x00007ffff50e4efb in g_file_monitor_emit_event (monitor=<optimized out>, child=<optimized out>, other_file=<optimized out>, event_type=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gio/gfilemonitor.c:275 #11 0x00007ffff5189879 in g_file_monitor_source_dispatch (source=0xc1c620, callback=<optimized out>, user_data=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/gio/glocalfilemonitor.c:546 #12 0x00007ffff4b4bae4 in g_main_dispatch (context=0x73d3b0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:3122 #13 g_main_context_dispatch (context=context@entry=0x73d3b0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:3737 #14 0x00007ffff4b4bd38 in g_main_context_iterate (context=0x73d3b0, block=block@entry=1, dispatch=dispatch@entry=1, self=<optimized out>) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:3808 #15 0x00007ffff4b4bffa in g_main_loop_run (loop=0x74ddc0) at /var/tmp/portage/dev-libs/glib-2.45.2/work/glib-2.45.2/glib/gmain.c:4002 #16 0x00007ffff6a2e3a7 in gtk_main () from /usr/lib64/libgtk-x11-2.0.so.0 #17 0x000000000041fd8d in main (argc=1, argv=0x7fffffffc6c8) at main.c:312