This was inconsistent, for everything else we follow symlinks,
unless StatResolveSymlink isn't set.
Details
see D27951
Diff Detail
- Repository
- R241 KIO
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 24395 Build 24413: arc lint + arc unit
This gonna change the behavior of the function compared to before the StatDetails stat patch (details = 3 returned the inode of the link and not the one of the link destination), but it make the behavior correct indeed and I doubt anyone did rely on the previous behavior.
I spent some time trying to to get some output of a qDebug() that I put in createUDSEntry(), but got the total sum of nothing; for future reference, any pointers? (I tried the kpropertiesdialog small patch from D27951 among other things).
Type kdeinit5 in a terminal, the output from ioslaves (created after that) will go there.
$ export QT_LOGGING_RULES="*kio*=true"
$ kdeinit5
from the build dir
$ LD_LIBRARY_PATH=./ QT_PLUGIN_PATH=./ kioclient5 openProperties ~/.bashrc
still not getting the qDebug() I put in createUDSEntry()... IIUC, qDebug() always worked regardless of the QT_LOGGING_RULES. I just wanted to see some output about the behaviour of "before" and "after" this diff.
Anyway, the patch makes sense, setting UDS_DEVICE_ID and UDS_INODE after "buff" has been modified/or not by the symlink resolution bits.
kdeinit5 is the one who needs to see that QT_PLUGIN_PATH in order to locate kio_file.so.
<cd builddir> $ export QT_PLUGIN_PATH=$PWD/bin $ kdeinit5 $ kioclient5 openProperties ~/.bashrc 19:23:54.253 kio_file(27069/27069) createUDSEntry HELLO AHMAD
HELLO! (you little twerp!)
Thanks a bunch, I've been trying to figure it out for a while...
(Now the other issue, "DEVICE" (from the kproperties patch) is always "8", whether I use ~/.bashrc, /usr/bin/file, or some file on a usb stick. But that's not really related to this diff).
That's really odd. And what does stat say?
E.g. I get
Device: fe01h/65025d
on one partition, and
Device: fe04h/65028d
on another. Those decimal values match the debug output from that kpropertiesdialog patch.
Sorry for the delay; it turns out statx is available on my system, so 'stat_dev(buff)' called:
inline static uint16_t stat_mode(struct statx &buf) { return buf.stx_dev_major; }
which is always 8 on my system.
I propose changing it to combine stx_dev_major and stx_dev_minor:
inline static uint32_t stat_dev(struct statx &buf) { return (buf.stx_dev_major * 100) + buf.stx_dev_minor; }
so for example:
$ stat /usr/bin/file | grep Device Device: 804h/2052d Inode: 9168 Links: 1 $ stat ~/.bashrc | grep Device Device: 803h/2051d Inode: 97 Links: 1
"DEVICE" (from kpropertiesdialog) would be, respectively:
804 803
I am not an expert on these low-level stat calls, but that seems to make sense to me anyway :)