Wine file explorer is extremely slow if navigating into mtp share

Open forum for end-user questions about Wine. Before asking questions, check out the Wiki as a first step.
Forum Rules
Locked
SSUPII
Newbie
Newbie
Posts: 3
Joined: Tue Apr 05, 2022 3:48 am

Wine file explorer is extremely slow if navigating into mtp share

Post by SSUPII »

Using Wine 7.4 with 32-bit prefix, but happens with 64-bit prefixes too.

I found this issue by loading a file by drag and drop from mtp into a program with a save dialog managed by the system (in this case, Wine).
The save dialog will default to the original location of the file and will take a very long time to load (up to two minutes), ending up extremely laggy until you manually leave the folder via the interface. There is no more lag once you leave the mtp share in file navigation.
With a small amount of testing I found this to happen on the Wine Explorer too. Explorer works normally, until the mtp mount point is reached and so starts to very heavily slow down.
I tried giving a mount letter to the mtp drive in-case it was an issue with the path

Code: Select all

/run/user/1000/gvfs/mtp:host=DEVICENAME/
but it doesn't fix the slowdown. It did fix the path being read-only as there is no forbidden symbols.

The log shows nothing different or out of the ordinary, just shell STUBS.

Code: Select all

0110:fixme:shell:IShellBrowser_fnOnViewWindowActive stub, 007DA458 (007DF760)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 007DA458 (2, 1026, a003, 0, 0079EBBC)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 007DA458 (2, 1026, a004, 1, 0079EBBC)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 007DA458 (2, 1025, a003, 1, 0079EBBC)
0110:fixme:shell:IShellBrowser_fnSendControlMsg stub, 007DA458 (2, 1025, a004, 1, 0079EBBC)
for every folder navigated, being unrelated to the issue I'm reporting.
hwertz
Newbie
Newbie
Posts: 3
Joined: Sat May 23, 2020 7:38 pm

Re: Wine file explorer is extremely slow if navigating into mtp share

Post by hwertz »

Just like to say "me too". But wtih s3ql. I think this may be general with fuse, that wine (..or whatever, but I do see it even just the wine-provided explorer.exe) may repeatedly make requests that on conventional filesystems are probably just pulling stuff out of the dentry cache, in fuse they make be making fresh requests each time which I expect would be orders of magnitude slower. The one suspicious-looking thing I see, I do see (with strace) like:

Code: Select all

95599 lstat64("/mnt/HDD/VirtualBox VMs", {st_mode=S_IFLNK|0777, st_size=22, ...}) =0
.....
95504 readlink("/mnt/HDD/VirtualBox VMs", "s3ql-fs/VirtualBox VMs", 260) = 22
95504 lstat("/mnt", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
95504 lstat("/mnt/HDD", {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0
95504 lstat("/mnt/HDD/VirtualBox VMs", {st_mode=S_IFLNK|0777, st_size=22, ...}) = 0
95504 readlink("/mnt/HDD/VirtualBox VMs", "s3ql-fs/VirtualBox VMs", 4095) = 22
95504 lstat("/mnt/HDD/s3ql-fs", {st_mode=S_IFDIR|0755, st_size=0, ...}) = 0
95504 lstat("/mnt/HDD/s3ql-fs/VirtualBox VMs", {st_mode=S_IFDIR|0775, st_size=0, ...}) = 0
95504 openat(AT_FDCWD, "/mnt/HDD/VirtualBox VMs", O_RDWR|O_NONBLOCK) = -1 EISDIR (Is a directory)
95504 openat(AT_FDCWD, "/mnt/HDD/VirtualBox VMs", O_RDONLY|O_NONBLOCK) = 92

So if I open up (in Windows parlance) Z:\mnt\HDD in explorer, it does that whole sequence of lstat /mnt, lstat /mnt/HDD, lstat /mnt/HDD/(whatever), readlink, lstat /mnt again, lstat /mnt/HDD/ again, then lstat /mnt/HDD/s3ql-fs, then lstat /mnt/HDD/s3ql-fs/(whatever) for EVERY SINGLE entry in there. (The items in /mnt/HDD are indeed symlinks.) I suspect lstat in fuse is uncached and slow. I wonder if a small "lstat cache" could be thrown in for this? Just having it hold the most recently used 2 "trees" (one for file and one in case it's a symlink for holding that second tree of lstat lookups) you would eliminate the redundant lstat calls. I'd assume it'd have some small but non-zero speedup on native filesystems too (I assume on them these lstats are coming out of the dentry cache so it's not taking so long.)
Locked