Filter by owner

[Paddy3118]

I like the presentation of the tool, but find it hard to use as typically we have multiple users using a drive and would like our IT support with root access to create the duc DB, but individual users only be shown their use. User1 should not be able to see data from any other user.

Nice graphics though, Thanks :-)

[zevv]

Quoting Paddy3118 (2018-10-12 10:31:49)

I like the presentation of the tool, but find it hard to use as typically we have multiple users using a drive and would like our IT support with root access to create the duc DB, but individual users only be shown their use. User1 should not be able to see data from any other user.

I'm afraid this is a variation on a recurrent theme: being able to selectively show or hide parts of the tree depending on properties like userid, atime, ctime, file size, etc. See issues #186, #153, #121 and probably others.

Unfortunately, this does not fit in the way duc currently stores the data when indexing. Duc recursively accumulates the size of all child files and directories of each directory, and stores only this accumulated total for each directory. To be able to bin totals by other properties duc would need to store totals for each user, or each time period, or each filesize, etc. This will probably make the database side explode, and adds considerable complexity.

The alternative would be to categorize at display time, but that would not scale at all: requesting the total disk space of a single user would require Duc to recursively traverse the whole database, with possible millions of entries to follow.

What I can do in the current architecture is have Duc do the filtering at index time: during indexing duc can be instructed to only count files which match certain filters, and put only those in the index. This is of course a crude solution: if you want to get the totals for a hundred users, you would need to run "duc index" a hundred times with different filters. That's bad.

Another solution would be to supply a list of filters before indexing, and have duc effectively create a different tree in the database for each filter. The fs needs to be traversed only once, but in the end there are a 100 different trees in the database, one for each user. This is also bad, since the database will now be a hundred times larger.

I'm still searching for an optimal solution for this problem. I guess there might be some kind of sweet spot possible where the complexity and work is split between index and display time, but I'm not at all sure yet how this can be solved.

Any ideas of insights on how to tackle this much appreciated.

Nice graphics though, Thanks :-)

That's the good thing: no one cares about the technical stuff as long as the graphics look cool :)

-- :wq ^X^Cy^K^X^C^C^C^C

[Paddy3118]

I hear you, and thanks for such a comprehensive reply. All the best with duc in the future.

[bougui]

Hello, is their a readme or a file the will help us do an index for a single user ?

index time: during indexing duc can be instructed to only count files which match certain filters, and put only those in the index.

I would love to be able to index only 1 or 2 users which used too much disk space, ;-) is this available in right now ?

And yes the graph are nice is anything else really important ?

Guillaume