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.
*** Bug 15324 has been marked as a duplicate of this bug. ***
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.
Created attachment 8785 better fix
Created attachment 8786 Shows a debug message if creation of folder monitor failed
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.
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.
Pushed to github to ease code reviews: https://github.com/alexxcons/thunar/commit/3d4e47f9bbb9803ad7fb8c03f9068dec65f3f7ed?diff=unified
Created attachment 8901 a proper fix Did minor changes according to code review
(In reply to alexxcons from comment #8) > Created attachment 8901 > a proper fix <stdin>:108: space before tab in indent. continue; 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!
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 https://git.xfce.org/xfce/thunar/commit?id=bb865a02482fd8fc8af92b41a5f0f373e7178dc7
> 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 !