Bug 369275

Summary: Virtual symlinks to large files are not visible
Product: [Frameworks and Libraries] frameworks-kio Reporter: Jonathan Doman <jonathan.doman>
Component: generalAssignee: Dolphin Bug Assignee <dolphin-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: archer_ame, kdelibs-bugs
Priority: NOR    
Version: 5.26.0   
Target Milestone: ---   
Platform: Arch Linux   
OS: Linux   
Latest Commit: Version Fixed In:
Sentry Crash Report:
Attachments: Correcting the buffer size for readlink.

Description Jonathan Doman 2016-09-24 05:47:40 UTC
Some symlinks are not shown at all in Dolphin, even though they are perfectly visible in Thunar, Konqueror, and ls.

I am using Dolphin 16.08.1 (Archlinux packages) to view files on a TMSU (https://github.com/oniony/TMSU) virtual filesystem. TMSU uses tags to generate a virtual hierarchical filesystem, with symlinks pointing to the actual files. Most of these links work fine in Dolphin, but any link pointing to a file bigger than exactly 2 GiB is totally missing. One thing I noticed is that unlike symlinks on a real filesystem which typically have a small size (< 100 B), the symlinks in the TMSU filesystem appear to be the same size as the file they point to, since they only exist in memory and have no disk size. The large files being pointed to show fine in Dolphin, as do symlinks to them made on a normal filesystem.

Reproducible: Always

Steps to Reproduce:
1. Install TMSU
2. mkdir test; cd test
3. truncate -s 2047M small.file
4. truncate -s 2048M large.file
5. tmsu init
6. tmsu tag --tags="file" *.file
7. mkdir tmsu-mp
8. tmsu mount tmsu-mp
9. ls -l tmsu-mp/tags/file (observe both symlinks)
9. dolphin tmsu-mp/tags/file (observe only 1 symlink to small.file)

Actual Results:  
Dolphin does not show link to large.file

Expected Results:  
Dolphin should show link to large.file, just like ls, Thunar, and Konqueror do.
Comment 1 Jonathan Doman 2016-09-25 01:00:50 UTC
After a little debugging, I figured out that dolphin relies on KIO for directory listings, and I confirmed the bug is in KIO with a simple test program that basically calls KCoreDirLister::openUrl("file://.../tmsu-mp/tags/file")
Comment 2 taro yamada 2016-10-23 13:51:48 UTC
Created attachment 101724 [details]
Correcting the buffer size for readlink.

Maybe I'm encountering the same bug and found the cause.
Could you try this patch?

(Since I am not a programmer, I do not know whether this patch is appropriate.)
Comment 3 taro yamada 2016-10-23 14:24:41 UTC
I'm sorry, it was not appropriate =(
Comment 4 taro yamada 2016-10-23 14:51:15 UTC
I'm sorry, it was completely inappropriate...

The cause of this bug seems that lstat returns strange size of symlink on some filesystem (for me, it returns 0 on /proc/self , /sys/bus/cpu/devices/* and so on) and then readlink fail.
Comment 5 taro yamada 2016-10-25 15:02:40 UTC
I tried to send a patch to the review board.
https://git.reviewboard.kde.org/r/129259/
Comment 6 Jonathan Doman 2016-10-26 05:41:05 UTC
Thanks for that patch. I think you definitely found the bug - I can see the "readlink failed!" warning message in the system journal.
Comment 7 Andreas Hartmetz 2016-10-29 19:14:04 UTC
Git commit 44512b6acbe6bb1c595e330bef702a0100d7bd4b by Andreas Hartmetz, on behalf of Taro Yamada.
Committed on 29/10/2016 at 19:13.
Pushed by ahartmetz into branch 'master'.

Sanitize the symlink name buffer size.

Currently, KIO uses lstat to get the buffersize for readlink.
But in certain situations, it returns an inappropriate value.

For example, "/proc/self" or "/sys/bus/cpu/devices/*" returns
its size is 0, and then readlink fails with EINVAL (so the
link won't be shown in KDE applications). TMSU seems to return
the target's actual filesize instead of the link size,
i.e. the length of the target's filename.

This patch limits the initial buffer size to sane values and
expands the buffer when needed. The behavior is similar to
ls, so it should be compatible with all filesystems.

REVIEW: 129259

M  +16   -6    src/ioslaves/file/file.cpp

http://commits.kde.org/kio/44512b6acbe6bb1c595e330bef702a0100d7bd4b