Trash sometimes visible, sometimes hidden

[axeld]

It seems that Tracker hides the trash directory on all volumes that were already mounted when it starts, but shows it on all volumes mounted later. Maybe that's just coincidence, though.

In any case, it's not consistent. It should be changed such that the trash directory is never visible IMO (you can still access it from the shell if you need to, but it doesn't really have a use from the GUI).

[anevilyak]

Will look into it, it should never be hiding it though. It will, however, still respect that hidden pose attribute if it's already written there, which would be reinstated if you ever happen to reboot into a Haiku or BeOS install prior to those changes (it used to forcibly write that attribute to all Trash dirs on startup). Will see if I maybe missed an edge case somewhere.

[anevilyak]

As for it being visible, by the way, I only made that change because at the time there seemed to be a consensus that people didn't think it should be hidden at all, though I'm too lazy to dig up the mailing list thread currently.

[anevilyak]

On second thought, maybe I'm getting confused between Trash and Desktop. Will figure it out after work either way.

[anevilyak]

Out of curiosity, can you dump the _trk/pinfo_le attributes on the Trash directories that are visible? FSCreateTrashDirs() at least marks them all invisible when it creates them.

[anevilyak]

Come to think of it, that might be the problem...FSCreateTrashDirs() is run on Tracker startup, but if the volume is new and mounted later, the trash dir will only be created once FSGetTrashDir() is called on that volume for the first time. The former writes the hidden and icon attributes to the directory, the latter does not. That should probably be changed, since FSCreateTrashDirs() calls FSGetTrashDir() to handle directory creation anyhow.

[anevilyak]

Can you try with the attached patch please?

[axeld]

That seems to fix it, thanks!

[axeld]

There seems to be a bad side effect, though: once I use the context menu, the full tracker icon is replaced with an empty one.

[anevilyak]

Care to elaborate? As in context menu on the desktop -> Trash or.. ?

[anevilyak]

I wonder...as part of that change I fixed a broken ifdef that theoretically would've resulted in the vector icon never getting written. Could you by any chance try changing the #ifdef HAIKU in FSGetTrashDir() to #if 0 and see what happens then?

[axeld]

The trash context menu on the Desktop, yes.

If I remove that block, everything works as intended.

[axeld]

BTW the code there always writes the empty icon, so even the BeOS icons shouldn't be written at that point this way.

Having had a closer look, I think FSGetTrashDir() either shouldn't do that, or should only do that if the directory does not exist yet.

[anevilyak]

Is there a way to determine that? From find_directory()'s signature, I don't see a way to determine if it did in fact have to create the directory or not.

[stippi]

find_directory has a parameter which tells it to create the directory if it didn't exist. So you could call it two times, if the first call failed, the folder did not exist. I also believe the icon should never be written unless you create the directory.

[anevilyak]

Tracker passes 'true' for the createit parameter. AFAICT, however, there is no return code or other mechanism to tell from the result that it was created as opposed to just already existed, apart from calling it twice, or using BEntry to determine if it existed beforehand. Will work around it later unless someone wants to beat me to it.

[stippi]

If you pass false for createIt, then it shoud fail no? So you know it doesn't exists. Then use use find_directoy a second time, with createIt=true, and add the icon. If you got no error the first time with createIt=false, don't write the icon.

[anevilyak]

Yes, it just would have been nice to be able to detect that situation without having to call it twice. Anyways, should be fixed in hrev36522, please verify.

[anevilyak]

Appears to work as expected here, closing as fixed. Please reopen if anyone sees any further regressions.

[axeld]

Finally fixed in hrev36524.