The media selection screen shows Trash folder entries for any folder with name .Trash

[prl]

If a directory other than a mountpoint/movie or mountpoint contains a folder called .Trash, then a Trash entry is shown for the folder in the media selection screen.

However:

• If the Trash folder is entered by navigating to it and pressing OK, the non-standard .Trash folder is opened and listed.
• If, in the folder containing the non-standard .Trash, RED Delete is used, the file deleted is not moved into the non-standard .Trash visible in the screen, it is moved into one of the standard .Trash folder.
• The non-standard .Trash folder is not cleaned when its entry is navigated to and RED Empty trash is pressed.
• The non-standard .Trash folder is never emptied by the automatic trash clean-up process.

The problem is due to tests like ".Trash" in path in the MovieSelection code and tests like path.endswith(".Trash") in both MovieList and MovieSelection. These weak tests are used in preference to the almost-correct MovieSelection.isInTrashFolder(), which appears not to be used anywhere in the code. The companion function MovieSelection.isTrashFolder() uses the weak path.endswith(".Trash") test, and so MovieSelection.isTrashFolder() can give results inconsistent with MovieSelection.isInTrashFolder() for the "trash folder" part of the path vs the complete path.

For example, MovieSelection.isInTrashFolder("/media/hdd/Archive/.Trash/fake.mpg") will return False, but MovieSelection.isTrashFolder("/media/hdd/Archive/.Trash") will incorrectly return True.

This problem was discovered when I noticed that a user had apparently renamed "/media/hdd/movie" (with its already-created .Trash) to "/media/hdd/Recorder TV".

Replication steps

Create directory "/media/hdd/Archive/.Trash".

Create a dummy media files "/media/hdd/Archive/fake1.mpg" and "/media/hdd/fake2.mpg".

In the media selection screen (MEDIA from live TV), navigate to "/media/hdd/Archive", then navigate to the Trash entry on the screen.

Press RED Empty trash.

Press OK to enter the Trash directory: fake2.mpg will still be listed, but /media/hdd/.Trash will have been emptied.

Press BACK to return to "/media/hdd/Archive". Navigate to fake1.mpg and press RED delete.

Re-enter the Trash in "/media/hdd/Archive". It does not contain fake1.mpg.

Navigate to "/media/hdd/Trash" (the system .Trash folder). It contains fake1.mpg (only fake1.mpg, because the previous actions will have emptied "/media/hdd/Trash".

[IanSav]

If we are changing the Trash processing I would like to suggest that there only ever be ONE .Trash per volume / device. The .Trash could be in the root directory of the device unless some other preference is expressed.

The Trash entry in MovieSelection should be made visible in all folders selected for browsing but the actual Trash folder is the one .Trash folder for the device / volume as suggested above.

The meaning of Trash in MovieSelection could change depending on the device being browsed. Alternatively the MovieSelection Trash view could be faked to show the current device's .Trash folder as the contents of Trash but links/sub folders can be provided to link to any other volume's .Trash folders that are currently available.

Empty Trash could then be configured to empty the current volume's trash, all trash folders or ask the user. Similarly pressing Delete on Trash would be the same as "Empty Trash" though pressing Delete on any of the linked volume .Trash folders within Trash would simply only empty the .Trash on the nominated volume.

[Peter Urbanec]

there only ever be ONE .Trash per volume / device. The .Trash could be in the root directory of the device

Consider the case where the user has a network mount. The root level of the mount has only read permissions, but the user is trying to delete content from a subdirectory that has read/write permissions.

[IanSav]

The .Trash doesn't have to be in the root, it is just an example (I thought I read that the network .Trash folders were in the root). The key point is that there should only be ONE .Trash.

[prl]

While I have some sympathy with the idea of a single trash directory per volume (even better, I think, might be a user view of the trash as a single system-wide directory, even though there are multiple physical trash directories, with at least one per volume), there are some complications, like the fact that the Trash directory can only be navigated into from the folder where it physically exists, and RED Empty trash is only active in that directory.

With a single unitary user view of trash, there's also the problem of it being hard for a user to tell when they want to move something out of the trash whether the operation will be a cheap rename (link/unlink), or a much more expensive copy/delete.

In any case, I think these ideas are out of scope for this bug fix and might be better served by open discussion on the forum.

Peteru's case of a read-only mount point is only solved by the present system if the media files and recording are in mountpoint/movie, which is a bit of a hackish way around the problem.