https://bugs.winehq.org/show_bug.cgi?id=39773
Bug ID: 39773 Summary: File->Open slowdown caused by desktop.ini checks Product: Wine Version: 1.8-rc2 Hardware: x86 OS: Linux Status: NEW Severity: normal Priority: P2 Component: shell32 Assignee: wine-bugs@winehq.org Reporter: fgouget@codeweavers.com Distribution: ---
To reproduce this you will need two Linux machines, a Samba server and a Samba client.
On the Samba server: * Create a directory with lots of subdirectories and files: mkdir smbdir cd smbdir for i in `seq 1 200`;do mkdir sub$i; done for i in `seq 1 200`;do touch file$i; done
* Export smbdir through Samba. (alternatively you could export '/' and use '/usr/lib' as a replacement for smbdir)
On the Samba client: * Mount the Samba share. You can either do it by adding a /etc/fstab line like: //MYSERVER/smbdir /mnt/smbdir cifs rw,username=MYLOGIN,password=MYPASSWORD,domain=MYDOMAIN 0 0
Or by starting Nautilus in GNOME, clicking on '+Other Places' -> Windows network... using GVFS. Note that in this case you'll have to work around the colon in the mount point filename (see bug 34868).
* Slow down the network connection using a command like this: tc qdisc add dev eth0 root netem delay 10ms
* Check the above line is effective by running: ping MYSERVER The rtt should be around 10ms.
* cd /mnt/root/ wine notepad
* Open the File->Open dialog, navigate to the smbdir folder exported through Samba.
* BUG: The initial display will be slow and scrolling through the many subfolders will be very slow.
* Change the file mask to '*.*'.
* Scroll all the way to the right so only files are visible. As long as only files are visible scrolling should then be very fast!
* Finally change the rtt to 0ms on the Samba server and check that the RTT is under 1ms.
* Now test again notepad's File->Open dialog and everything should be reasonably fast.
The problem is that whenever File->Open displays a folder in the open file dialog it checks whether it contains a desktop.ini file to display the right icon. That's not cached, thus incurring a few file lookups per folder displayed. For local file systems that's fast enough but on network shares with a non-trivial RTT the speed impact is significant. A 10+ ms RTT makes the dialog essentially unusable.
Note that when displaying a filename we have everything in the cache so redisplays are lightning fast and track the mouse.
Also Microsoft Office has the same problem even though it does not use the standard comdlg32 dialog (though that may depend on the Windows version being emulate). On Windows Microsoft Office suffers no slowdown in this situation. What this means is that the standard common dialog is probably the wrong level for fixing this.
Hacking SHELL32_GetCustomFolderAttributeFromPath() in shell32 to just return FALSE speeds things up greatly. The display still lags a bit behind the mouse so that there may be some residual file lookups or other slowdowns but it's still night and day.