(2017-04-04, 15:08)trogggy Wrote: (2017-04-04, 01:04)ronbaby Wrote: That having been noted, I thank you again, hakmawongzi, for telling me about this option, which, as I've said, I didn't even know existed until today. (And frankly, I question the value of it. Why would anyone even want to hobble the Kodi user interface by deliberately disabling UI capabilities? That makes no real sense to me.)
I wouldn't if I was the only one who used it.
If I'm handing a remote to someone who's likely to dribble on it I'd rather they're not two clicks away from deleting files.
It's an interesting point. I'm still not sure that i am persuaded of the value of this option.
In my own personal case, all of my content is sitting on an NFS file server, which is in a whole separate room from where my Kodi HTPC (and my flatscreen) are located.
I only mention this because I am thinking: If I want to protect a set of files so that some naive users with access to my Kodi HTPC box can't delete them, maybe the simpler, more precise, and more minimalist/elegant way to do that is to just go onto the NFS file server and set permissions/ownership on the relevant directory/directories so that the directories themselves are read-only for user/group/world, as appropriate.
logically, one would think that this would be both adequate and effective, thus eliminating the need for Kodi to contain any special controls over this functionality at all, but...
Caveats and Quirks:
*) Obviously, in order to make protection from deletion/renaming work properly, e.g. on an NFS or SMB file server, the person administering that file server has to kinda know what they are doing, at least a little bit. But it isn't fundamentally hard to do.
*) I just now performed a simple experiment where I enabled this option (allow file delete/rename) over on my second desktop system (running Ubuntu 16.04 + the latest Kodi 17) and then I tried to delete a file on my NFS fileserver which was in a directory owned by some different user-ID than the one I was logged in as on the Ubuntu system, and where the permissions of the directory were set to 0755 (directory write enabled only for directory owner). Right clicking on the test file brought up the menu which now included
Delete as an option, of course, but when I clicked on that (and then confirmed that yes, I really did want to delete the file), nothing happened. The file was not deleted, and
no error or warning message ensued.
The fact that the file was not deleted is entirely appropriate under these circumstances, of course. This is exactly how it should work and demonstrates the point that protecting files from deletion is/was already well within the capabilities of either NFS or SMB file servers (and that it is thus redundant to implement this kind of protection in Kodi also). The troubling part is that when file deletion from within Kodi, fails, e.g. due to permissions, it appears that there is no code within Kodi that's even checking the return code from the unlink() call and/or which would provide the end luser with some helpful message along the lines of "
Sorry dude, but that operation failed due to permission settings".
(In fact, I'm somewhat surprised that there have been no naive users who have popped up in these fora and posted to say "
Hey! I clicked to delete this file and nothing happened! What's up with that??)
I guess that I'll file a formal bugreport in the tracker suggesting that the return code from unlink() be checked and that if failure occurs, the user should be shown some helpful message noting the failure.
