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

In D28388#637417, @ahmadsamir wrote:

(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.

In D28388#637419, @dfaure wrote:

In D28388#637417, @ahmadsamir wrote:

(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 :)

In D28388#638722, @ahmadsamir wrote:

...

Open a diff to have a focused conversation.

In D28388#638986, @meven wrote:

In D28388#638722, @ahmadsamir wrote:

...

Open a diff to have a focused conversation.

Good point. Thanks. :)