non-existent temporary desktop file appears on desktop #944
Comments
wxl
changed the title
|
ok, can confirm that the report is valid - played a bit with i guess we can break it down a bit - and make it far more simple to reproduce. Steps to reproduce:
Thats all, i guess we are to fast with the desktop refresh, |
|
I did it more than 10 times but couldn't reproduce it. I don't have Debian or Ubuntu but the distro shouldn't be important if there's a bug. I may have seen a similar thing before fundamental changes to libfm-qt's Would you please paste the name of that none-existent file (or attach a screenshot)? BTW, a desktop reload from pcmanfm-qt's window may be enough; there's no need to log out and log in. |
|
see the attached screencast 🕶️ Edit: ok - i really guess that it is a timing probkem with the repaint of the desktop |
Oh, Falkon has a problem here (although this is my old laptop). I saw it after reloading the page. |
|
falkon don't have any problems, falkon is a problem - would you knowingly run an far outdated chrome or chromium? |
It's easy to know if you can reproduce it: when you see it, open the desktop folder inside pcmanfm-qt's window. If it's there, it isn't related to desktop repaint. Tell me the result please! |
Don't blame falkon; I like it ;) The version installed here should be outdated. |
|
The name of the file will change, ultimately, but it's always one of the desktop shortcuts, which means one of:
and it has a random six digit alphanumeric string appended to it. There's two screenshots above that show examples:
|
|
@wxl - one could see it in the screencast |
Yes, I saw them after reloading the page. Important question: Do you see them when you open dekstop inside pcmanfm's window? |
Good question. Yes. But not in terminal, as with @agaida 's result above. |
|
YES, Sir! |
|
So, we can be sure that it isn't about desktop repaint. DAMN!! 2 bugs in one day (although the first one is solved). |
|
What's really sad is that I saw this in development of Lubuntu 19.04 but we had so many other things to worry about and it wasn't always showing up that I just shrugged it off. At least the impact is relatively minor. |
|
@tsujan - i don't blame falkon, the outdated part is QtWebengine - and i don't really know how it can work to have it up to date for distributions |
|
@wxl - no problem, shit happend. It's not nice, but don't have much negative impact. On the pro side - it did not occour such often, so most of the users will not see it, esp. on real machines i guess |
|
ok, F5 in the pcmanfm-qt window let it disappear |
Yes, refreshing inside pcmanfm-qt solves it. But logging out and back in brings it back, at least in Lubuntu. |
|
dito in debian, but not every time, gone at the second and third re-login - there is something racy |
|
no problem with testing it - i was surprised that i never seen it before |
|
@tsujan Happy to test. I can absolutely get it to reproduce every time. What distro are you using BTW? I can see if I can't figure out the right steps to reproduce. |
|
the only thing that makes me nervous is the existence of an unwanted temp file - it should never be created first hand. |
|
It's another case of finding a needle in a haystack. It'll be found at last; I hope soon. Anyhow, thanks for tellng me about it! |
|
//me reduce the haystack to libfm-qt and pcmanfm-qt. Duck and crawling away ... |
Manjaro but it shouldn't make a difference. It's about a race. So, it depends on the computer. |
|
@wxl - how many processors do you use in vbox - i use 4 out of 8 right now |
libfm-qt, more probably. |
1/8 |
|
with 1 out of 8 and only 1024M it is reproducible nearly every time |
|
@wxl @agaida Please don't forget to restart pcmanfm-qt's process after installation and before testing! |
|
I changed it to a PR: lxqt/libfm-qt#408. It corrects a flaw that had remained in the logic. |
|
And again - why is that file created first hand? |
Unbelievable! What I corrected was a flaw but, apparently, there's still another one.
When GLib creates the desktop file, it writes to a temp file and then deletes it. Qt does so too. |
|
@agaida I added a commit to lxqt/libfm-qt#408; please try it again! |
|
I installed Manjaro on VirtualBox, installed my LXQt packages on it and succeeded in reproducing this problem. But when I open desktop inside a pcmafm-qt window too, no nonexistent file item is created. Only if desktop isn't opened inside a pcmanfm-qt window, nonexistent file items can be seen. Do you confirm this? |
|
it trigger something, i guess you will not like it
Hard to understand - here is the screencast |
|
Yes, I can see everything now but have no clue about the cause yet :( It took me 2 hours to install Manjaro + upgrade it + fix virtualbox additions in it (nasty, shouldn't have done it with virtualbox ISO) + upgrade to Testing + install my LXQt packages in it. But, at last, I can see it. |
|
Found it, at last! The cause was VERY hidden and fairly complex: At the moment of clicking Apply or OK, desktop folder is reloaded and, simultaneously, that temp file is created by GLib, so that the directory list job adds it as an item (because it exists at that very moment). Then, the directory monitor starts emitting change events (because directory monitor starts before directory list job) and announces the creation of that file and, immediately after that, reports its deletion too. Our code sees a creation followed by a deletion and thinks it's a good idea to ignore both of them (1 + (-1) = 0). The final result is that an item is added independently from the directory monitor and its deletion is ignored afterward; hence a nonexistent file remains on desktop. The solution is very simple: when deletion happens immediately after creation, take both of them into account, instead of ignoring both of them. Now, I should find a way of adding a short comment to the code... EDIT: I corrected my mistakes in the above explanation -- especially the orders. |
Fixes lxqt/pcmanfm-qt#944 Previously, if a file was in addition queue and then it came into the deletion queue, its addition and deletion were both ignored. That was wrong and could result in showing nonexistent files because addition can also happen in directory list job before being processed by file info job. Also process accumulated changes only after finishing the current info job and don't clear all deletion paths after processing them (because, logically, only those paths that can be deleted should be removed).
|
Squashed the commits of lxqt/libfm-qt#408 and reworded its title and body. Tested it with 1-2/8 CPU cores under VirtualBox. GLib temp files were immediately deleted after being created. |
Fixes lxqt/pcmanfm-qt#944 Previously, if a file was in addition queue and then it came into the deletion queue, its addition and deletion were both ignored. That was wrong and could result in showing nonexistent files because addition can also happen in directory list job before being processed by file info job. Also process accumulated changes only after finishing the current info job and don't clear all deletion paths after processing them (because, logically, only those paths that can be deleted should be removed).
|
for debian it is easy, just uploaded - when built i will file a unblock bug again :) - for Lubuntu it is a bit different, it is already in the wild. Don't know the update/fixing policy for non-LTS versions, but if a update is possible i would suggest to do a cumulative update with all the things that are in sid (only bugfixing, no new functionality) Edit: The changes is not that invasive, i hope that the release team will allow it. |
|
I'm torn about this, frankly. I see some justification to getting it in Disco through the Stable Release Updates process, as it is kind of ugly, but it's a bit of work for a relatively small impact. Thoughts, @tsimonq2 ? |
|
@wxl IMO, it was quite important and Lubuntu shouldn't let its users suffer from it. |
|
Yeah @wxl, let's do it. Want to do the paperwork or should I? |
|
@tsimonq2 you can do it if you've got the gumption.
|
|
Sorry, this issue is not exactly the place to discuss Lubuntu issues, but I am just wondering, when is the fix for this going to land in 19.04 if you guys actually decided to push it? It's just incredibly infuriating and it's the only thing that still keeps me on Xubuntu. |
|
@tannisroot the fix is already in Debian. @tsimonq2 will have the fixes merged to Eoan/19.10 shortly. Meanwhile, we'll get an SRU bug filed to get it into Disco/19.04. Meanwhile, there is a workaround that will keep the thing out of your field of vision for a session:
If you have further questions or comments about the status of this in Ubuntu, I would urge you to direct your comments at the downstream bug. Thanks! |
On some machines (slow enough?), visible desktop entries such as 'trash' would cause related temporary no longer existing files being displayed on the desktop as well. - lxqt/pcmanfm-qt#944 - lxqt/libfm-qt@f944be7d Package-Manager: Portage-2.3.66, Repoman-2.3.12 Signed-off-by: Jimi Huotari <chiitoo@gentoo.org> Closes: gentoo#12108 Signed-off-by: Andreas Sturmlechner <asturm@gentoo.org>
Especially when toggling desktop shortcuts on and off, the desktop displays non-existent files in the form
{desktop shortcut}.desktop.{6 digit random alphanumeric string}.Debian testing
Lubuntu 19.04
Expected Behavior
Current Behavior
The shortcuts display correctly, but the additional non-existent file sometimes shows. There is an unambiguous way to reproduce (see below), but it's not consistent:
pcmanfm-qtis restarted in Lubuntu, the errant file goes away, but logging out and back in again returns the problemPossible Solution
The shortcuts do display correctly, so my guess is this is a recycling issue, but I cannot be sure. The fact that it doesn't occur in all situations is interesting, as well. My guess is that this is an issue with a rename as I suggested above since I can see when things behave correctly, it looks like a file appears on the screen and then disappears. Maybe it's a timing thing?
Steps to Reproduce (for bugs)
Debian testing
computer.deskop, but with a 6 digit alphanumeric string appended to it.user.desktopinstead of acomputer.desktopLubuntu 19.04
user-home.desktopwith a 6 digit alphanumeric string appended to itcomputer.deskop, but with a 6 digit alphanumeric string appended to it.user.desktopinstead of acomputer.desktopContext
Um, it would be nice to have a less messy desktop? ☺
System Information
Debian testing
Lubuntu 19.04
The text was updated successfully, but these errors were encountered: