Show file/directory user (owner), group and permissions in tree view

[justinsutw]

Any plan to show the folders/files with their owners' name?
And also do owner statistics?

These features will be very useful in a multi-user environment.

[shundhammer]

What do you have in mind?

Break down the entire tree into subtrees with the respective owner at as an (artificial) toplevel item?

If yes, this would mean to come up with a list of pseudo or system users to exclude; surely you wouldn't want to clutter such a display with files belonging to root or any of the rest of the 50+ system users that a typical Linux system has.

KDirStat did have a "write mail to user" feature, but with today's setups this doesn't work anymore since nobody runs a local sendmail or other MTA locally anymore, so there is no reasonable match between the Linux user name and a mail address. You just can't send a mail anymore to user kilroy (implicitly on localhost); you'd need to know the rest of the mail address, i.e. kilroy.brown@mydomain.com.

[shundhammer]

For quite some time, I was thinking about a "details" subwindow (or popup?) and reduce the number of columns in the tree view that are shown by default. If that view is to show any more columns like owner and group, this would definitely be needed.

But I wouldn't want to add those two more columns to the default view because the vast majority of Linux systems only have one real user (besides the 50+ system users mentioned above), so that would mostly add to the screen clutter.

Let me think about this.

[justinsutw]

I think a tree with username at the top and subtrees showing the largest directories he own will be terrific. I personally don't mind seeing system users shown with regular users, as this analysis will probably only be used on some shared data volume, where very few system files exist. Regards, Justin

…

On Tue, Jul 17, 2018, 1:10 AM Stefan Hundhammer ***@***.***> wrote: What do you have in mind? Break down the entire tree into subtrees with the respective owner at as an (artificial) toplevel item? If yes, this would mean to come up with a list of pseudo or system users to exclude; surely you wouldn't want to clutter such a display with files belonging to *root* or any of the rest of the 50+ system users that a typical Linux system has. KDirStat did have a "write mail to user" feature, but with today's setups this doesn't work anymore since nobody runs a local *sendmail* or other MTA locally anymore, so there is no reasonable match between the Linux user name and a mail address. You just can't send a mail anymore to user *kilroy* (implicitly on *localhost*); you'd need to know the rest of the mail address, i.e. ***@***.*** ***@***.***>* . — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATA97va5fd5i1qHVBhRoQMDSPK1RvHHGks5uHZvdgaJpZM4VRoEP> .

[justinsutw]

I agree that the owner information might not be useful for the single-user systems. Therefore, making these columns optional is totally appropriate. Regards, Justin

…

On Tue, Jul 17, 2018, 1:23 AM Stefan Hundhammer ***@***.***> wrote: For quite some time, I was thinking about a "details" subwindow (or popup?) and reduce the number of columns in the tree view that are shown by default. If that view is to show any more columns like owner and group, this would definitely be needed. But I wouldn't want to add those two more columns to the default view because the vast majority of Linux systems only have one real user (besides the 50+ system users mentioned above), so that would mostly add to the screen clutter. Let me think about this. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATA97m901vrjj0-l-Uol7w9hhBnaZKmqks5uHZ8CgaJpZM4VRoEP> .

[shundhammer]

First simple approach in branch

https://github.com/shundhammer/qdirstat/tree/huha-file-owner

You might want to remove this section from ~/.config/QDirStat/QDirStat.conf:

[TreeViewColumns]
ColumnOrder=NameCol, UserCol, GroupCol, PercentBarCol, PercentNumCol, TotalSizeCol, OwnSizeCol, TotalItemsCol, TotalFilesCol, TotalSubDirsCol, LatestMTimeCol
VisibleColumns=NameCol, UserCol, GroupCol, PercentBarCol, PercentNumCol, TotalSizeCol, OwnSizeCol, TotalItemsCol, TotalFilesCol, TotalSubDirsCol, LatestMTimeCol
Width_GroupCol=auto
Width_LatestMTimeCol=auto
Width_NameCol=auto
Width_OwnSizeCol=auto
Width_PercentBarCol=auto
Width_PercentNumCol=auto
Width_TotalFilesCol=auto
Width_TotalItemsCol=auto
Width_TotalSizeCol=auto
Width_TotalSubDirsCol=auto
Width_UserCol=auto

Then you will get additional columns for User and Group that are hidden by default. You can show them as usual in the tree header:

Not removing the section from the config file puts them all the way to the right. I had that initially because I thought that QDirStat is all about file sizes, not owner and group, but for an old-time Linux/Unix user like me this looks so unnatural; so by default, they are at the left just like the output of ls -l.

But of course the user can always rearrange the columns as he likes; the only exception is the name column which always comes first (this is enforced).

[shundhammer]

So far, sorting by user or group sorts by the numeric user or group ID, not by the user or group name alphabetically: Translating the uid to the user name or the gid to the group name is a quite expensive operation, and for sorting it means going through all the items in a directory, not only the visible ones.

I might look into setting up my own cache for this since the glibc functions that do that, getpwuid() and getgrgid(), appear to be quite slow (I'll have to check that). Until that time, the sorting is by numeric uid / gid.

[shundhammer]

So, the initial request of this issue is done with this (pending a merge to master, of course).

I can't make any promises for advanced by-user statistics, but I'll keep thinking about it. As usual, it's more difficult than one might think initially. Stay tuned.

[shundhammer]

So, did you try it? Does it help you in what you want to achieve?

[justinsutw]

I will try installing a copy in my Windows to test it. Regards, Justin

…

On Sat, Jul 21, 2018, 2:17 PM Stefan Hundhammer ***@***.***> wrote: So, did you try it? Does it help you in what you want to achieve? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#80 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ATA97vT-3RP53OD78IBXCWqpMdSInrOmks5uI5qBgaJpZM4VRoEP> .

[shundhammer]

No response

[shundhammer]

Also added file permissions both in symbolic mode ("rwxr-xr-x") and in octal ("0755").

Now that it's so many more columns, I moved those that are not essential to the purpose of QDirStat (i.e. user / group / permissions) all the way to the right.

Note: None of those columns appears by default; a user can enable them by right-clicking in the tree header and using the context menu there.

[shundhammer]

Merged to master.

[ferencek]

Will this feature also work with cache files produced using the qdirstat-cache-writer script?

On remote machines I usually produce cache files using this script and then analyze locally by starting the GUI and reading the cache file.

[shundhammer]

Will this feature also work with cache files produced using the qdirstat-cache-writer script?

Sorry, no. The information is not stored in the cache files: No uid, no gid, not even permissions (just the object type -- directory, plain file, symlink, ...).

That was a good reminder, actually; the information displayed for such cached items was very misleading, showing root/root as the owner and 0000 permissions. I just fixed that to not show anything in this case.

While it would of course be possible to extend the cache file format to include that information as well, there are several problems with that:

• The cache file format (since it is simple and well-specified) is also used by some backup tools. I would prefer not to break it for them.

• Adding permissions would be as easy as adding the octal number. But uid and gid are another matter: They might be different between your server where you collect the data with qdirstat-cache-writer and your desktop machine where you view them with QDirStat.

Writing the user and group names as text (rather than the numeric uid and gid) would mean that each in-memory item (QDirStat::FileInfo and QDirStat::DirInfo) would have to store them as text as well. Not only would that blow up the memory footprint of QDirStat's in-memory data (think about 500,000 FileInfo and DirInfo objects for a typical Linux root filesystem), it would also mean to retrieve them immediately when reading directories - the underlying syscalls only return the numeric values. That would mean some serious caching in QDirStat internally; you can never know if a machine doesn't use an LDAP sever somewhere on the network to store user information, and fetching each user name via the uid from such a server would be very expensive.

So, for the forseeable future, sorry, no user or group names and no permissions for cached items.

[ferencek]

Thanks for the clarification, I completely understand the concerns.

If extending the cache file format is not too much work, a middle ground solution might be to have the storage of the user, group and permissions info in the cache file optional and disabled by default. That way any other tools relying on the current file format would not break.

I recently had a case where some files got accidentally deleted and because of the way the filesystem recycle bin is configured (per user), I was really missing the user info from a QDirStat file system snapshot that I took a few weeks earlier. With that info available, it would have been trivial to figure out who owned the deleted files and could restore them from the recycle bin. This is actually why I ended up here after googling around for this feature.

[shundhammer]

I see your reasoning. Let me think about it.

So the use case here is really to find the right trash directory for restoring files. Maybe some longer term history of certain actions would be a lot more useful here? Like, say, another log where they are recorded and that does not rotate away after four program invocations?

[ferencek]

If I understood your proposal correctly, there would be an extra log file containing the user, group and permissions info for the file system and would not be regenerated from scratch every single time the program or script is started. If so, that sounds like a good idea and would certainly be less expensive to run. I guess there would have to be some way of tracking new and deleted files, but that should not be too difficult (changes in the user, group and permission info for the existing files are probably less trivial, but perhaps also less critical, at least in my use case).