! Please note that this is a snapshot of our old Bugzilla server, which is read only since May 29, 2020. Please go to gitlab.xfce.org for our new server !
Ghost files remain after moving files on a sftp remote


Description alexxcons editbugs 2019-07-12 10:07:35 CEST
Steps to reproduce:
- Connection e.g. via sftp (other remotes may show the same bug), to a folder with files
- Select some file(s) and move them to the parent folder (e.g. via drag & drop )

Result: The files actually will be moved, but the thunar still shows all of them in the child folder, though they are not there any more.

The mayor difference to local file systems is, that "g_file_monitor_directory" will return an error "this gvfs backend does not support file monitors" (or similar).
( TODO: Display a notice to inform user on that. Currently this error is just ignored )

I was a bit surprised to see that no ghost files remain after move for nautilus. (as well uses gvfs).
However as well Nautilus is not able to track moves/renaming when done via 3rd party software e.g. via console. So it as well has no folder monitor available for sftp.

Instead I guess Nautilus just updates the containing folder after each internal move/rename operation, instead of only relying on the file_monitor.  I think thunar should do the same.

In addition: So far I dont understand why there are ghost files for moving files upwards, but not so, if the files are moved downwards.
Comment 1 Alexander Kurakin 2019-07-12 12:59:40 CEST
*** Bug 15324 has been marked as a duplicate of this bug. ***
Comment 2 alexxcons editbugs 2019-07-15 23:58:57 CEST
Created attachment 8777 
preleminary fix

Very preleminary fix

This hack already works for "move".

A real fix should be more generic and robust (TODO: Use same code for renaming) . As well the fix only should be triggered for remote locations which dont support file-monitors in order to avoid unnecesarry refresh-triggers on local folders.

IMO it would makes sense to add a method like "hasFileMonitor" to ThunarFolder.
Comment 3 alexxcons editbugs 2019-07-18 10:52:38 CEST
Created attachment 8785 
better fix
Comment 4 alexxcons editbugs 2019-07-18 10:54:07 CEST
Created attachment 8786 
Shows a debug message if creation of folder monitor failed
Comment 5 alexxcons editbugs 2019-07-19 23:30:51 CEST
Created attachment 8793 
improved fix

Added small improvement to minimize the impact for local "g_file_move".

I am still not happy with the solution, since it happens that, like in the previous ghostfile bug, some ghost files may remain in the source folder.

That is, because "g_file_move" is a async operation ... and if I call "thunar_folder_reload" directly after it, it possibly is not finished yet.
"g_file_move" allows to pass a "  GFileProgressCallback" .... I tried that, but for some reason which I do not understand yet, "thunar_folder_reload" will fail when called via the callback .. instead a endless spinner will be shown (possibly related to a bug with creating/removing symlinks on remotes?) ... to be further investigated.
Comment 6 alexxcons editbugs 2019-08-11 22:24:44 CEST
Created attachment 8867 
a proper fix

I am confident that this time I found the real cause of the problem:

Currently "thunar_application_launch" reloads the ThunarView after any file operation, but only if it is provided.
Hovever moving files, either via drag and drop, or via keyboard shortcuts does not pass a ThunarView to the method. 
For local filesystems thats no problem, since there anyhow is a folder monitor running on each ThunarFolder which will reload the view if something changes. (Sidenote:  It looks like currently the view reload is triggered twice for local file systems. Directly, and via the folder-monitor)

For some gvfs remotes, there is no folder monitor running. So we need to trigger the reload manually.
The atached patch does not blindly reload the view any more (if provided at all), instead it gathers all containing folders of all source/target files of an operation and only reloads them if they dont run a folder monitor.
Comment 7 alexxcons editbugs 2019-08-12 11:12:47 CEST
Pushed to github to ease code reviews: https://github.com/alexxcons/thunar/commit/3d4e47f9bbb9803ad7fb8c03f9068dec65f3f7ed?diff=unified
Comment 8 alexxcons editbugs 2019-08-17 23:50:50 CEST
Created attachment 8901 
a proper fix

Did minor changes according to code review
Comment 9 Andre Miranda editbugs 2019-08-26 01:18:40 CEST
(In reply to alexxcons from comment #8)
> Created attachment 8901 
> a proper fix
<stdin>:108: space before tab in indent.
warning: 1 line adds whitespace errors.

Took me while to realize it was needed to apply the patch from comment 4 before this one :)

I can reproduce this issue with a ssh connection and the patch solves the problem, thanks!
Comment 10 Git Bot editbugs 2019-08-26 22:21:15 CEST
Alexander Schwinn referenced this bugreport in commit bb865a02482fd8fc8af92b41a5f0f373e7178dc7

After a file operation, reload relevant parent folders directly instead of reloading the provided view (view not provided e.g. on DnD or DBus event) - Only reload folders manually if no folder monitor is running to prevent double-reloads. (should save some performance) - This will reload the view correctly even if the location does not support folder monitors - It as well fixes a Bug #15704 - Ghost files remain after moving files on a sftp remote

Comment 11 alexxcons editbugs 2019-08-26 22:26:27 CEST
> Took me while to realize it was needed to apply the patch from comment 4 before this one :)
Eh, sorry  :F  .. just learned that it is possible put multiple commits into one file .. next time I'll do that :)

Only pushed to master, since it is a very fundametal change.

whitespace error is fixed.

Thanks for testing !

Bug #15704

Reported by:
Reported on: 2019-07-12
Last modified on: 2019-08-26
Duplicates (1):
  • 15324 Thunar doesn't refresh directory list after moving file out from remote


CC List:
2 users



preleminary fix (1.78 KB, patch)
2019-07-15 23:58 CEST , alexxcons
no flags
better fix (4.60 KB, patch)
2019-07-18 10:52 CEST , alexxcons
no flags
Shows a debug message if creation of folder monitor failed (1.27 KB, patch)
2019-07-18 10:54 CEST , alexxcons
no flags
improved fix (4.88 KB, patch)
2019-07-19 23:30 CEST , alexxcons
no flags
a proper fix (17.07 KB, patch)
2019-08-11 22:24 CEST , alexxcons
no flags
a proper fix (17.42 KB, patch)
2019-08-17 23:50 CEST , alexxcons
no flags

Additional information