mirror of
https://github.com/bootandy/dust.git
synced 2026-06-08 11:29:05 +03:00
[GH-ISSUE #340] Filter by file age #156
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @MolbioUnige on GitHub (Oct 31, 2023).
Original GitHub issue: https://github.com/bootandy/dust/issues/340
I am looking for a way to take in account only files that are older then a given value. Would that be possible to implement?
In my institue, people are making experiments that weight a few terabytes each. People are required to remove their data once their treatment is completed, but some tend to forget. So, I'd like to find a way to find who is sitting on old stuff and thus preventing other users to use the servers.
@bootandy commented on GitHub (Nov 7, 2023):
That is an interesting idea,
It should be possible to implement. I'll leave this issue open
@smf8 commented on GitHub (May 10, 2024):
Hi, As I've last checked with the master branch. This hasn't been implemented yet and I'm interested in helping out if that's OK.
I'm fairly new to Rust and so I apologize beforehand but I've got a couple of questions.
Should this filtering happen in file walking stage? (like in
ignore_filewhich takes some filtering (e.g. regex) into account)Or is it better to apply it when extracting
DisplayNodefromNodes?I think the latter might be more beneficial since It can also address #385 by building the
heapbased onageinstead ofsize.@bootandy commented on GitHub (May 11, 2024):
That's a good question.
In this case with a hard limit I would say: this filtering happen in file walking stage (probably).
However it might be fun to try it both ways.
For https://github.com/bootandy/dust/issues/385 however it would probably come from when: extracting DisplayNode from Nodes. Even thought the tasks sound similar they might not be in code.
I'm not sure of the above myself yet though, so I may well change my mind!
@wugeer commented on GitHub (May 16, 2024):
Hello, I'm fairly new to Rust and so I apologize beforehand but I've got a couple of questions. I am trying to deal with this problem, but I encountered a problem
In other words, is it better to use relative time, absolute time, or epoch-based time as input?
@codeswhite commented on GitHub (May 27, 2024):
Hey, I had an idea,
Consider supporting suffix-parsing for the duration for example:
30sfor 30 seconds5mfor 5 minutes2hfor 2 hours2day4hoursThis way it will be much more intuitive and powerful.