Sometimes when I open a folder in Thunar it takes very long (~10 seconds) to display its content. As far as I have checked this seems to have nothing to do with the folder's size or the amount of files in it and it isn't exactly reproducible, usually if it took that long one time, the next time when I try to access the folder the content is displayed in normal speed (immediately), but the problem can occur later again with the same folder. It seems to be independent from the choosen view-mode, but it obviously does NOT happen if I access the folders by the tree-view on the left of the program window. I'm using Ubuntu Breezy amd64 as OS and compiled Thunar from source according to the manual on the wiki-pages.
Thunar tries to guess the file type from the extension (if possible), but that is not always possible. So for certain types of files (i.e. ELF executables on UNIX/Linux) it has to open the file first to determine the type. Now if you try to open a folder with a lot of files, which Thunar has to open to determine the file type, it will take some time for the operating system to read the files from the disk. The next time you open the folder, (relevant parts of) the files will be cached in memory and so the folder is loaded immediately.
Well, if it would only happen at folders with large content, I would of course not fill out a bug report, but this seems totally independent from the folder's size and content, this problem also occurs if the concerned folder contains only a single small text file. And as I stated above, it does never happen when I access folders by clicking on them in the tree-view on the right side, so this behaviour seems to look like a bug for me.
Hm, does the UI freeze in the meantime? Or do you see the animated throbber in the topleft corner?
The UI doesn't freeze, if I click on anything on the tree-view while Thunar tries to access a folder that long, the directory above this folder appears again. And when I then try again to access the folder where Thunar "hung" before, it is displayed at normal speed, just like all other folders in the same directory. But if I choose another folder in either a subdirectory or a totally different directory, it probably "hangs" again.
What kind of file system?
I have tried reiserfs-, ext3-, and ntfs-partitions, exactly the same behaviour on all of this filesystems.
Does it also happen when using the shortcuts pane instead of the tree pane?
I have tested it, if I use the shortcut-pane, I can't reproduce this behaviour anymore indeed, when I switch back to tree-view the problem appears again.
Ok, I think I've seen the problem today using the tree-view. Thunar entered the folder, and the throbber did not stop (empty folder). But unfortunately I cannot reproduce that anymore. Just to be sure: You also see the animated throbber after entering the folder, but it doesn't stop loading?
(In reply to comment #9) > Ok, I think I've seen the problem today using the tree-view. Thunar entered the > folder, and the throbber did not stop (empty folder). But unfortunately I > cannot reproduce that anymore. Just to be sure: You also see the animated > throbber after entering the folder, but it doesn't stop loading? > Exactly.
Created attachment 510 Suggested patch Please try this patch. Should fix the problem.
I have tried it, but unfortunatelly it seems as if it didn't solve the problem, the only difference is that the delay now is ~5 seconds instead of ~10 before.
Created attachment 520 Next try Please try this patch. It restructures the job handling to avoid the race conditions causing the trouble.
Sorry to bring bad news but even with this patch the delay is still there, the behaviour doesn't seem to have changed compared with the last patch.
(In reply to comment #14) > Sorry to bring bad news but even with this patch the delay is still there, the > behaviour doesn't seem to have changed compared with the last patch. I've committed the patch now (as it really improves things). Unfortunately I'm unable to reproduce your problem anymore. I'll have a look at the tree model again to check for other possible race conditions.
The patch had a race condition, can you check the patch attached to bug #1743? (requires latest version of Thunar from SVN)
Once again bad news, even this patch leaves the problem unsolved. Don't know if it helps but I have testet the Xubuntu Dapper Drake Live-CD (amd64, can be downloaded from http://cdimages.ubuntu.com/xubuntu/releases/dapper/beta-2/ ) recently, the version of Thunar there shows exactly the same behaviour than on my Breezy installation.
Hm, not reproducible on an i386 Xubuntu test box. I don't have access to an amd64 right now. Can you retry with the latest revision, there were a few fixes that could be related to this one.
Jani, did you see this one on Xubuntu recently?
(In reply to comment #18) > Hm, not reproducible on an i386 Xubuntu test box. I don't have access to an > amd64 right now. Can you retry with the latest revision, there were a few fixes > that could be related to this one. > Did that, but still reproducible :-(
I've not seen this since I use only the shortcut view. But now I have tried and after a few clicks through the dirs I got a throbber for about 4 seconds in a relatively small dir.Hmm tried again and the whole UI of thunar froze.This is revision 21434. I'll try a newer one and also reproduce it again.stracing the frozen thunar shows many small reads() of 32 bytes from descriptor 3, and then many writes of 16K to the same descriptor. I'll try to gather more data.
That'd be helpful.
I have clicked around today as well for a good while but could not reproduce again. Will try some more.
I could make it happen again about 3 times in ~15 minutes but I see not pattern :(
Moving to 0.4.0rc1.
I think I fixed this recently. Can you try with the latest SVN version?
Good News, seems as if the bug is gone indeed, I can't reproduce it anymore :-) Thanks a lot!
Finally. ;-)
The bug reappeared in the current svn version :-(
Anything special about the folder?
No, like before it happens all the time on random folders. The bug is definetly NOT present on version 0.3.3svn-r22930, if that helps.
I have made a deeper research, the bug reappeared exactly on revision 22934.
I investigated further, the first version without the bug was revision 22920. Interestingly this also seems to be first revision which included the sort of "enhanced" navigation toolbar, while revision 22934 is the first one where the toolbar has been reverted again to its previous look (and the first one which includes the bug again). So this bug could maybe be related to the navigation bar?
Hm, probably. Do you use the pathbar-style or toolbar-style navigator?
It happens with both. (In reply to comment #34) > Hm, probably. Do you use the pathbar-style or toolbar-style navigator? >
I think I have good news: Today I replaced on my system Ubuntu Dapper with Ubuntu Edgy and checked out the version Thunar from the Edgy repository. Surprisingly the bug seems to be gone with this constellation, so I would suppose that this is maybe not a bug of Thunar itself but some issue in another software (GTK?). At least I'm quite satisfied :-)
Fine. I'll close this one then... finally. ;-)
Hm, no this is not fixed. But I'm finally able to reproduce it. Seems to be related to GtkEntryCompletion in GTK+ 2.10.
Fixed with revision 23747. 2006-11-06 Benedikt Meurer <benny@xfce.org> * thunar/thunar-path-entry.c(thunar_path_entry_changed): Changing the model currently in used by a GtkEntryCompletion is very slow with recent GTK+ versions. Therefore we disconnect the model first when changing the folder and reconnect it to the entry completion after- wards. Bug #1681.
*** Bug 2533 has been marked as a duplicate of this bug. ***