Changing recorded file to read only

[Mickkie]

I want to set some recordings as read only, to avoid inadvertently deleting them. I have looked in help for a button or menu setting, but haven't found anything. Is it a matter of using 'chmod 0444' on the .ts file, or will this break things if someone presses the delete button? Are there any other files I should also change?

[abu baniaz]

I don't know what the answer is, but try it. You can also use the chattr command.

https://www.geeksforgeeks.org/chattr-command-in-linux-with-examples/

[birdman]

I want to set some recordings as read only, to avoid inadvertently deleting them.

You could create a "Keep" folder and move such things into there.
Won't stop you deleting them, but might provide a reminder that you don't wish to.

[Mickkie]

Thanks guys,

A "Keep" folder will need subdirectories, to match the categories of recordings (Films, News, Documentaries, etc.) mirroring the current storage folders. This can lead to an error by absent minded users, when they won't realise they're in the depths of the "Keep" filesystem.

I tried chmod on a .ts file, it didn't work. The recording was moved to .Trash without any warnings. I suppose the delete/move command runs as root.

Then I tried 'chattr +i' on the .ts file. This succeeded in keeping the .ts file into its original folder, along with a newly generated .ts.meta file. All other than the .ts files, including .eit were moved to .Trash. I could set the .eit file as immutable too, but all cut marks on the recording will be lost.

I think this requires a programmatic function, so that marked recordings generate a warning and ask for interactive input from the user before they can be deleted.

[ccs]

You can disable the automatic deletion of items in the trash can after n days.

Or copy the recordings you want to keep somewhere else.

[Mickkie]

Yes, a back up off the main directory will protect from erroneous deletions, but eat up storage for duplicated files. Disabling automatic deletion would work, as long as no one empties the .Trash manually, which tends to happen frequently before even the automatic deletion kicks in.

[ccs]

Sounds like they're intent on deleting your recordings whatever you try.

[Willo3092]

Just create a new folder on /media/hdd/ and bookmark it.

[BrokenUnusableAccount]

I've never seen an OS where setting a file to read only has any effect on whether you can delete it.
It's certainly not that way in Linux.

Now if OpenViX didn't run everything as root you could probably do it by changing the owner of the files.
However OpenViX does run everything as root.

[birdman]

Preventing deletion at the OS level is probably not useful here anyway. All that would do is either:

• produce an error message when you do try to delete it, or
• produce no error message, but leave the file in place - leading to some confusion.

What would be better is for the file browser to have a (toggling) mechanism to mark the recording as non-removable, indicate it as such in the listing and behave accordingly.
If it's worth doing at all.

[ccs]

If it's worth doing at all.

Precisely.

Maybe remap the red delete key to something else, that would slow them down, and there would still less obvious ways to delete recordings.

[Mickkie]

Precisely.

Maybe remap the red delete key to something else, that would slow them down, and there would still less obvious ways to delete recordings.

Heh! The red button and increasingly the green and blue buttons too has become less receptive to input, hence all users are now trained to delete recordings via Menu > '3'.

I recall the old Topfield STB had a setting to mark recordings as "Protected", which stopped users from deleting them. I suppose this is not a general requirement for e2, or someone would have coded it by now.

[ccs]

....deleted.

[abu baniaz]

....deleted.

The whole point is to prevent this.