Trash: Ability to see "sent to Trash" date (easy)

[mmadia]

Being able to sort Trash's contents by chronological order may be a useful feature. Possibly could be implemented by adding a "Trashed" attribute, which essentially a timestamp.

[stippi]

Awesome idea. Such a simple solution to a problem I had once in a while.

[waddlesplash]

Moving Tracker enhancement tickets out of R1 milestone -- Tracker's source code comes from BeOS R5, so it already has all the features it did on R5.

[thangdinh1298]

I'm attempting to solve this.

[eml]

thangdinh1298 are you still working on it?

[thaflo]

Replying to eml:

thangdinh1298 are you still working on it?

I don't think so. Would you doing that?

[stellarpower]

Proposed fix:

• Add a _trk/date_time_trashed attribute to
  • tracker's viewable ​attributes
  • ​terminal app
• Get current system date and time, generate and add this attribute when trashing a file
  • ​here
  • and in the terminal app
• Remove this attribute when restoring
  • ​here
  • and in the terminal app
• Add this attribute as a default column visible for trash directories (and original name (path), whilst at it)
  • TODO - work out after completing the above as more complex
  • Edit the Model in ​Model.cpp????

((Don't think I can assign myself but would happy to be owner of this))

[nephele]

You don't need to be the ticket owner to work on something, mentioning your intent on the ticket is normally enough :)

Perhaps watching the trash directory and adding the attribute to new entries would be a more comprehensive fix than trying to patch everything that might touch that dir, unless it isn't a directory but a querry, I am unsure about that.

[madmax]

Replying to nephele:

Perhaps watching the trash directory[...]

And there's already ​a watcher to update the icon state. I don't know how functional, reliable and immediate they are, or how much work it would be, but maybe the addition and removal of _trk/original_path could also be moved there from both tracker and bin/trash?

[stellarpower]

I'd have to look in detail, but IIRC I got the impression the watcher was just keeping an eye out to change the icon from empty to containing files. Also we have the problem then that once the item is in the trash, the reference to the original path has been lost - I think it kinda needs to be atomic and there won't be a way around that. However, the idea of refactoring it out I would agree with, as an option at least, in that case bin/trash could reduce down to a very small number of lines, just probably not in the watcher

Edit: sorry, missed the comment above on my phone. I think the trash was kind of like a unison between directories, I don't know if it is a quesy underneath but I saw a mention to being a model aggregating all the trash directories on mounted filesystems. I'd vote for having one unambiguous programmatic way of moving a given entry or set of entries into the trash, presumably as part of the tracker kit, and if needed, refactor anything else to make use of this.

[nephele]

For the option of using watch directory, that should be immidiete afaik, you would only need to watch the Trash dir(s) for new additions and then set the current time, i don't think the deleted path can be set in the same way since the file is already moved then. Downside to this is that if Tracker closes for whatever reason that this then breaks in an unexpected way.

[stellarpower]

Were there any particular advantages for putting it in the watcher? Just that to me, it feels probably more robust to have this attribute added or cleared at the point the file is (un)trashed, esp. if this is already done for the path. What would be reasons for favouring putting it in the watcher?

Also, there seems to be quite a mélange of code for working with times in the tracker, I was wondering if there would be a justification to refactor this to use the date/time classes in the support kit. This would be a larger job that could potentially break a lot of things of course, but am wondering if it would be worth it down the line. It seems the Time attribute type is backed by time_t (and not all the *attr utils in /bin seem to support it fully). It might be nice for users to be able to add dates, times, and datetimes to their custom attributes, and even though it's working now, I reckon quite a bit of what is dealing with times currently in tracker could be cleaned up and unified. I'd have to look again specifically, but I saw various calls to strftime and friends that I am guessing could be pulled under the locale kit better.

[nephele]

A watcher is usefull to cover all cases where something can be moved, in the case of the Trash dir it could be for example.
mv file /boot/trash/
cp file /boot/trash/
cat file | cat > /boot/trash/file

It's not really feasible for us to patch every operation that could end up in the trash, since the intent isn't always clear. But the question would be too if that even matters.
For the tracker code itself, it was released as opensource and came from BeOS directly, some of the code could really use improvements, though I can't personally verify if the date stuff is part of it, if we have proper ICU code to work with dates it probably makes more sense to use that to cover all edge cases ICU already covers.

[stellarpower]

Gotcha. Are those examples valid use of the Trash? I had assumed it was a system directory and so behaviour would only be agreed if it was left alone and the normal way of doing it used.

Also thought as much with the sources, the copyright date I saw was quite old too. The fix just for this would be quite quick to submit; part of me would be keen to go further with some of the other enhancements regarding dates etc., and part of me thinks if potentially quite a few bits in Tracker could do with an overhaul it may be best to leave it as it is for now rather than kinda leave a dent in the older code.

[code_vaibhav]

I want to work on this ticket.I have a few questions though.

• Each volume/device has a Trash directory (which is hidden) only one Trash directory

is visible which is on the boot partition. The watcher watches for Trash directory on all volumes but those are hidden. Shouldn't it watch only the Trash directory which is visible?

• As suggested by @nephele "last trashed" attribute should be added to each new entry.

If we have the entry_ref of the new entry how do we add an attribute to it. I thought of using SetAttrInfo() but it is for a filetype. Please help me on this.

[nephele]

It should watch every Trash directory, Trashing is an operation local to a partition/disk because a move in such a context is non-destructive and really fast. A copy to another disk is not, it takes a long time and could be error prone, and untrashing would be slow again.

For UI simplicity all Trashes are represented as a single trash however, but that isn't how it works behind the scenes :)

[nephele]

Looking at the documentation think manipulating attributes is done via a BRessource. Perhaps another dev can confirm that.

​https://www.haiku-os.org/docs/api/classBResources.html

[bipolar]

There's also ​https://cgit.haiku-os.org/haiku/tree/headers/os/kernel/fs_attr.h, as used by /bin/addattr: ​https://cgit.haiku-os.org/haiku/tree/src/bin/addattr/addAttr.cpp#n46.