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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
