enhancement: size of graveyard

[JeromeSchmied]

I've just installed this great tool, seems amazing.

One thing that would make it even better would be I think to show disk usage by graveyard. Something like with rip -i, eg. rip -s:

graveyard: /tmp/graveyard-user/
428 files in 3 directories: 131M
    file,              2K: /home/user/.viminfo
     dir,   2 files,  81K: /home/user/.w3m
     dir, 425 files, 130M: /home/user/.cache

or something.

Would be awesome.

[MilesCranmer]

Thanks and good idea. The one potential issue with the simplest approach to this [see below] is I think it might take longer to delete files, right?

For example, right now we can get away with simply a fs::rename for many cases which is very cheap:

https://github.com/MilesCranmer/rip2/blob/c0e30920079ac81ef54779106858002d397a052f/src/lib.rs#L284-L286

But if we want to add more info to the record, like size and filecounts:

https://github.com/MilesCranmer/rip2/blob/c0e30920079ac81ef54779106858002d397a052f/src/record.rs#L10-L14

I think it would take longer.

---

Alternatively, maybe we could compute this on-the-fly? Like, if you do rip -s, it could compute sizes by walking through the graveyard, rather than from the record. Wdyt?

Could even use the same code that e.g., dua-cli does for some of this.

[JeromeSchmied]

I think the 2. solution you mentioned would be perfect. So just compute sizes on-the-fly when rip -s

[MilesCranmer]

I wonder if it would be possible to simply pipe it to lsd or something? https://github.com/lsd-rs/lsd

Then you could pass whatever arguments you would normally pass to ls. I guess we would need to add something for 'time file was deleted' or something.

[JeromeSchmied]

Good idea.

[MilesCranmer]

I'm looking at https://github.com/zhiburt/tabled/ for doing this.

[JeromeSchmied]

looks like an amazing library

[MilesCranmer]

I also wonder if we could instead modify https://github.com/Byron/dua-cli to get some kind of interactive restoration... Seems like a fair amount of work though.