Suggestion to keep the type of a file or directory in the stat field st_rdev.

[Stef Bon]

Hi,

I've posted a suggestion about making the reading of directories
faster when the fileystem is considered to be slow. Recent versions of
the KDE dir listning calls, do not lookup the mimetype and .directory
files when dealing with a remote or FUSE filesystem. Below is the
message about storing information in the st.st_rdev field, which is
not used for "normal" files and directories. I did not get a reply
there, so I better post it here. What about it?


begin message:



I've been looking for a problem of this issue. I aggree that a
backthround thread or other process doing the (slow) reading of
mimetype and .directory files might work and bring the reading a lot
faster.

But the problem here is what causing this. First the determination of
the filetype (mimetype for regular files). It can be slow, and doing
that over and over again is silly. Why not use the field st_rdev part
of the stat struct. It's not used for regular files, and large enough
to hold an unique id to a (standard) database of filetypes.

This st_rdev attribute is only used special files as far as I know,
and is zero for regular files and directories. On my machine the type
is or unsigned long int, or better unsigned long long int.

In any case it's big enough.

It's safe to use an id, A mp3 file will not turn in a ogg file
suddenly, a pdf will never become a doc or something else.
Apps creating these files can set this value, and apps using the file
can set it when it's not been set before, or correct it when not set
to the right value.

When using this value, there is no other process required, it comes to
an app like dolphin just like the mode (filetype, owner, group,
permissions, times) does.

Futher when it comes to directories, the reading of the .directory
file is a time consuming task. In my FUSE fs, I'm using the mimetype
for directories like:

mimetype="inode/directory;role=remote.net.smb.network"

for the directory representing the SMB network for example. More examples:

local.map.system.programs
local.dev.cdrom.audio
local.map.documents
local.map.audio

etc.

Because the mimetype gives you a default icon (just like this mimetype
does for regular files) it's not required to use a .directory file for
setting and using the .directory file for an icon.
And it's possible to store this mimetype for directories also in the
st_rdev field.

I'm not saying that .directory files are useless, but using the
mimetype for directories can speed up things. And - as I see it -
directories can have a special meaning within the context of the
computer or the user, and till now there is no way to set this. Using
the role part of the mimetype makes that possible.

Stef