ghost files remain after moving files

While 1.6.11 seems to have fixed the crashing issues, this bug is still present for me.

To replicate, move a bunch of files out of a directory.
The last one to be moved looks like it hasn't been moved because their is a ghost entry still present in the detail view.
Ctrl+R to refresh the view removes it but the reload should be triggered automatically.

Confirmed seeing this - in fact I moved a 'bunch' of files and all the moved files were apparently still in the source folder till reload

I have seen this using icon view. It is not consistently doing it though; sometimes it was fine, sometimes 1 or 2 files would remain visible. I guess it is a threading issue.

Actually, I forgot to add that I only use Detailed View and the bug is definitely present there.

Compact view ...

I've seen also where a file gets added to an already opened instance of thunar at the correct location - nothing is there until I reload.

Created attachment 7048
unrefreshed thunar

At the point when I stopped zsync Thunar should show these files:

zesty-desktop-amd64.iso
zesty-desktop-amd64.iso.zs-old
zesty-desktop-i386.iso
zesty-desktop-i386.iso.part

still appears, XFCE 4.12

moving files. After moving in thunar source window shows one file that is still not moved. But actually it is moved and not exsist in source.
Compact list view.

still present in thunar 1.8.2.
It also happens when extracting an archive.
The archive might extract a folder, then rename it the temporary one and you end up with an incorrectly named folder requiring a refresh to see the renamed one.

Can reproduce the problem. Happens for all views, not only detailed view.

+

- create some empty files in some folder
- move them out of the folder (either by cut + paste, or via drag & drop. will be the same result )

I'm now using Thunar 1.82 in the Xubuntu test ppa. The bug is still present. In fact, it is worse if anything. There is ALWAYS a ghost file left after moving files.

This pretty much always happens when moving two or more files via drag and drop from Thunar to the desktop. I tried to debug the issue and noticed that removing the following if block helps: https://git.xfce.org/xfce/thunar/tree/thunar/thunar-folder.c#n607

*** Bug 14704 has been marked as a duplicate of this bug. ***

> removing the following if block helps: https://git.xfce.org/xfce/thunar/tree/thunar/thunar-folder.c#n607
Good spot ! I can confirm that removing the block helps (= removing the whole method).

A bit obscure: Removing just the "if" contition ( always executing "thunar_folder_reload") as well helps.

I'll further investigate to understand whats going on here.

- Removing "thunar_folder_file_changed" is not an option, because like that, "mv test1 test2" in an open folder will not be recognized by thunar.

- Removing only the if (G_UNLIKELY (folder->corresponding_file == file)) is as well bad, since this will cause many unnecesarry folder reloads.

The Problem comes from "thunar_folder_reload" beeing executed repeatedly.

Each reload stops a job and than starts a new job. A stopped, stopped/unfinished job may lead to:
(thunar:2655): thunar-CRITICAL **: thunar_folder_finished: assertion 'folder->content_type_idle_id == 0' failed
That will cause the view to dont update.

... to be further investigated

Last time I worked on thunar code, that reload stuff was a big mess and did not even work for jobs (copying, moving files). What makes it more complicated is that there are folder reloads and file reloads. I couldn't fix it completely, and if you change one part, it often breaks the other parts. I believe the proper solution would be to create a reload queue that gets processed regularly (e.g. while idle) and confined to a single place. That way, reloads could also be prioritized if necessary and perhaps unneeded/duplicate reloads could even be avoided (network accesses for example are quite expensive regarding performance). It could be more complicated than the current implementation, but the current implementation looks also complicated and is hard to understand, so maybe it doesn't matter.

Thanks for that hint !

Before going for a central reload queue, I'll see if I can find a more simple fix.

My plan would be to add a minimal delay before doing a reload of a specific thunar-folder (via g_timeout_add). And after that delay, only the latest "reload trigger" is considered, so that burst-triggers only result in a single reload.

.. will see if I can come up with some patch soon. (hopefully not breaking something else ;)

Created attachment 8658
patch

Attached a patch to fix the concrete bug .. the approach seems to work suprisingly well.

Possibly it makes sense to use the same burst prevention for other "reload" triggers on other thunar components.

I randomly picked a delay of 100ms. However burst prevention as well seems to work fine with 10ms, or only 1ms delay .. any preferences ?

Would be great to have some more testers before I push this fix.

> However burst prevention as well seems to work fine with 10ms, or only 1ms delay
Wrong: On 1ms it happens occasionally that there is still a ghost file. On 10ms it happens very seldom. On 100ms so far I did not see any ghost file so far. So 100ms seems to be okish. Probably the minimum depends on hardware.

The patch fixes my test case in comment #11.

Thanks for testing !
Before commit, I will try as well some other approach, since my current fix feels a bit squishy (depends on a magic number)
Strictly seen, my patch fixes a different problem (bursts). The patch just makes this bug harder to appear (and harder to reproduce).

*** Bug 15324 has been marked as a duplicate of this bug. ***

Created attachment 8693
a better patch

The actual problem of the ghost files is triggered because the used FileMonitor is destroyed and re-created on each "thunar_folder_reload". Because of that, some notifications of the FileMonitor are lost, leading to missing folder reloads.

While trying to figure out why one would want to destroy the FileMonitor on each folder_reload, I found that we currently use a deprecated FileMonitor flag "G_FILE_MONITOR_SEND_MOVED".
See details here: https://developer.gnome.org/gio/stable/GFile.html#G-FILE-MONITOR-SEND-MOVED:CAPS

Since sooner or later we need to exchange this flag, I just did so (See patch) to my suprise fixing the deprecated enum item as well fixed this bug.

However I dont fully understand the new functionallity yet, since it looks like only "G_FILE_MONITOR_EVENT_MOVED_OUT" is triggered, the other are not, while it looks like there are no regressions.

On top I still need to figure out if it makes sense at all to destroy and re-create the FileMonitor.

Created attachment 8745
Finally a proper patch

The last patch I posted had the downside that it required GIO v2.46 to work, so it is not possible to apply it to 1.8.x .. even for thunar master it would require a GIO bump. (besides that it does not fix the actual problem)

Attached a patch which fixes the actual problem, which is the permanent re-creation of the file monitor on each refresh of the folder.

The patch as well removes a single, superfluos "thunar_file_reload" which caused trouble when left there.

May I ask you to take another try for this new patch ? I did all testing which came to my mind .. but you never know ... possibly you have some exotic network file-systems around for testing ?

This new patch resolves the issue too. I did not test anything special other than my mentioned test case.

Alexander Schwinn referenced this bugreport in commit c53d11d9b1b948da7e266dc1cc3cc7d9602f42bd

Dont restart the folder monitor on each refresh - Fixes "ghost files after moving files" (Bug #13364)

https://git.xfce.org/xfce/thunar/commit?id=c53d11d9b1b948da7e266dc1cc3cc7d9602f42bd

Alexander Schwinn referenced this bugreport in commit bf4c333dbca1de6cd384e68a5caff027808a48bd

Dont restart the folder monitor on each refresh - Fixes "ghost files after moving files" (Bug #13364)

https://git.xfce.org/xfce/thunar/commit?id=bf4c333dbca1de6cd384e68a5caff027808a48bd

Thanks for testing !

I moved the creation of the folder->monitor into the constructed, since it is anyhow only created once, gave it some more testing, and now pushed it to master and 4.14

Actually I as well wanted to push to the 4.12 branch, but I just realized that it there seems to be some bug for this branch, giving me a blanc thunar window on starting it.

Will push to 4.12 later, when I found out what causes that extra-wiredness.

Alexander Schwinn referenced this bugreport in commit 3e78c775d0cb6185b39172d211ef0a7ac5ebaf27

Dont restart the folder monitor on each refresh - Fixes "ghost files after moving files" (Bug #13364)

https://git.xfce.org/xfce/thunar/commit?id=3e78c775d0cb6185b39172d211ef0a7ac5ebaf27

Pushed for 4.12 as well ... was some system wide glitch on my side.

I just realized the via a sftp connection, all files will remain as ghost files after moving them one folder up.
It's not a regression, was like that before.

I'll open a new bug for it and see if there is a simple fix.

Thanks very much!

> I'll open a new bug for it and see if there is a simple fix.

I hoped that's the same bug :(

(In reply to Alexander Kurakin from comment #30)
> I hoped that's the same bug :(

It's something different for sure. See the details here: Bug#15704

*** Bug 14755 has been marked as a duplicate of this bug. ***

*** Bug 14754 has been marked as a duplicate of this bug. ***