Bug #392913 was marked as fixed for 5.50, but I'm on 18.10 (with 5.50 as I understand it) and have a remaining issue:
NTFS volumes mounted via fstab as:
UUID=123456789 /mydrive ntfs defaults,umask=007,gid=46 0 0
...are visible if I navigate to / in dolphin, but symlinks to the mounted directory are not. E.g. if I do:
ln -s /mydrive /tmp/mydrive
...and then navigate in dolphin to /tmp, "mydrive" is invisible unless hidden files are shown.
I note that "mydrive" is in my dolphin "places" list.
ntfs-3g 2017.3.23 integrated FUSE 28
Linux hostname 4.18.0-11-generic #12-Ubuntu SMP Tue Oct 23 19:22:37 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Nate Graham asked that I file a new bug rather than re-open the older bug.
Weird, I did check for symlinks in the code for ignoring the root volume's hidden flag.
const QString fullFilePath = QDir(filename).canonicalPath();
Huh, I see the discussion at https://phabricator.kde.org/D13782
And it does look like that code is in place as you describe: https://cgit.kde.org/kio.git/tree/src/ioslaves/file/file_unix.cpp?h=v5.50.0#n567
I don't know if the umask matters, but as reported above, I use umask=007 in /etc/fstab
Hi, just wanted to chime in and say that it looks like I'm affected by the same bug. Copying my comment from 392913:
I'm experiencing what seems to be the same issue on two separate computers with KDE Frameworks versions above 5.50:
Computer 1: Vanilla Arch Linux with Dolphin 18.12.1 with KDE Frameworks 5.54.0
Computer 2: Manjaro with Dolphin 18.12.1 with KDE Frameworks 5.53.0
On both computers, I have NTFS volumes mounted via fstab with default options. Example:
UUID=0123456789ABCD /mnt/windows ntfs defaults 0 0
If I then have a symlink under home that points to this directory:
windows -> /mnt/windows
The symlink only shows in Dolphin if I turn on "Hidden Files" (Alt+.). It makes no difference if the links are made via Dolphin, from the command line etc (and I refreshed multiple times to be sure the links were in Dolphin's view of the FS).
This seems to be the same bug, but it's still present in KF > 5.53.0. Should I open a new report with this info?
LMK if you need more information or want me to try anything.
Of note, it seems to be the exact same behavior, but I can confirm this is happening with both KF 5.53.0 and 5.54.0 on Dolphin 18.12.1.
Also, on the discussion of umask: on Computer 1, I left the mask setting to default in fstab (0022 for Arch), and set it to umask=0000 in fstab on Computer 2.
Well, I can confirm the problem with symlinks here (dolphin 18.12.1, Qt 5.12.0, KF 5.54.0), which is a bit strange because I explicitly tested symlinks back in https://phabricator.kde.org/D13782 and it worked fine then (with the mentioned followup change)... :-/
I did some investigation, and the problem seems to be that ep->d_type = 10 now (which is DT_LNK), i.e. the "if (ep->d_type == DT_DIR || ep->d_type == DT_UNKNOWN)" branch is not taken anymore for some reason.
So the fix should be to change that to:
if (ep->d_type == DT_DIR || ep->d_type == DT_UNKNOWN || ep->d_type == DT_LNK)
I'll test it and submit a patch to phabricator later...
(In reply to Wolfgang Bauer from comment #4)
> So the fix should be to change that to:
> if (ep->d_type == DT_DIR || ep->d_type == DT_UNKNOWN || ep->d_type == DT_LNK)
Works for me :-)
The fix is on phabricator now:
Fantastic -- thanks!
Awesome, thank you!
Git commit 01a7e0e757d3558e131d24fbb079b65af7b70572 by Wolfgang Bauer.
Committed on 03/03/2019 at 11:53.
Pushed by wbauer into branch 'master'.
Fix NTFS hidden check for symlinks to NTFS mountpoints
A symlink to the mountpoint of an NTFS partition can have the type
So extend the check to cover that case as well.
Differential Revision: https://phabricator.kde.org/D18479
M +1 -1 src/ioslaves/file/file_unix.cpp