! 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 !
After moving files, a Ghost file sometimes remains


Description slumbergod 2017-02-18 16:42:40 CET
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.
Comment 1 flocculant 2017-03-02 13:44:38 CET
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
Comment 2 Will 2017-03-10 17:28:05 CET
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.
Comment 3 slumbergod 2017-03-10 17:58:22 CET
Actually, I forgot to add that I only use Detailed View and the bug is definitely present there.
Comment 4 flocculant 2017-03-10 18:04:04 CET
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.
Comment 5 flocculant 2017-03-11 12:10:53 CET
Created attachment 7048 
unrefreshed thunar

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

Comment 6 BalTun 2018-10-26 13:22:29 CEST
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.
Comment 7 slumbergod 2018-10-26 18:46:49 CEST
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.
Comment 8 alexxcons editbugs 2018-10-26 22:48:48 CEST
Can reproduce the problem. Happens for all views, not only detailed view.

Comment 9 alexxcons editbugs 2018-10-26 22:50:27 CEST
- 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 )
Comment 10 slumbergod 2018-11-12 03:30:37 CET
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.
Comment 11 Theo Linkspfeifer editbugs 2019-05-23 02:03:07 CEST
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
Comment 12 Theo Linkspfeifer editbugs 2019-05-23 02:27:30 CEST
*** Bug 14704 has been marked as a duplicate of this bug. ***
Comment 13 alexxcons editbugs 2019-06-15 23:37:42 CEST
> 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.
Comment 14 alexxcons editbugs 2019-06-19 23:24:31 CEST
- 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
Comment 15 Harald Judt editbugs 2019-06-19 23:42:09 CEST
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.
Comment 16 alexxcons editbugs 2019-06-20 22:33:46 CEST
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 ;)
Comment 17 alexxcons editbugs 2019-06-20 23:20:38 CEST
Created attachment 8658 

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.
Comment 18 alexxcons editbugs 2019-06-20 23:31:01 CEST
> 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.
Comment 19 Theo Linkspfeifer editbugs 2019-06-21 13:16:42 CEST
The patch fixes my test case in comment #11.
Comment 20 alexxcons editbugs 2019-06-24 23:17:06 CEST
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).
Comment 21 Alexander Kurakin 2019-06-25 15:00:17 CEST
*** Bug 15324 has been marked as a duplicate of this bug. ***
Comment 22 alexxcons editbugs 2019-06-27 14:44:03 CEST
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.
Comment 23 alexxcons editbugs 2019-07-10 00:07:15 CEST
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 ?
Comment 24 Theo Linkspfeifer editbugs 2019-07-10 19:41:00 CEST
This new patch resolves the issue too. I did not test anything special other than my mentioned test case.
Comment 25 Git Bot editbugs 2019-07-11 14:10:56 CEST
Alexander Schwinn referenced this bugreport in commit c53d11d9b1b948da7e266dc1cc3cc7d9602f42bd

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

Comment 26 Git Bot editbugs 2019-07-11 14:12:41 CEST
Alexander Schwinn referenced this bugreport in commit bf4c333dbca1de6cd384e68a5caff027808a48bd

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

Comment 27 alexxcons editbugs 2019-07-11 14:23:09 CEST
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.
Comment 28 Git Bot editbugs 2019-07-11 14:29:39 CEST
Alexander Schwinn referenced this bugreport in commit 3e78c775d0cb6185b39172d211ef0a7ac5ebaf27

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

Comment 29 alexxcons editbugs 2019-07-11 14:35:42 CEST
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.
Comment 30 Alexander Kurakin 2019-07-11 14:39:55 CEST
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 :(
Comment 31 alexxcons editbugs 2019-07-12 10:09:25 CEST
(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
Comment 32 alexxcons editbugs 2019-10-17 09:54:54 CEST
*** Bug 14755 has been marked as a duplicate of this bug. ***
Comment 33 alexxcons editbugs 2019-10-17 09:59:09 CEST
*** Bug 14754 has been marked as a duplicate of this bug. ***

Bug #13364

Reported by:
Reported on: 2017-02-18
Last modified on: 2019-10-17
Duplicates (3):
  • 14704 after cutting files from a folder , thunar auto select some files remained in the folder
  • 14754 Thumbnails in some rare cases not shown
  • 14755 Incorrect lists of files in 1.6.15


CC List:
8 users




unrefreshed thunar (75.97 KB, image/png)
2017-03-11 12:10 CET , flocculant
no flags
patch (2.78 KB, patch)
2019-06-20 23:20 CEST , alexxcons
no flags
a better patch (3.57 KB, patch)
2019-06-27 14:44 CEST , alexxcons
no flags
Finally a proper patch (3.57 KB, patch)
2019-07-10 00:07 CEST , alexxcons
no flags

Additional information