Write-protect certain addon file to prevent overwrite from update

How would I effectively protect one file in an addon from being overwritten on an addon update? My previous attempt to disable write permissions for it did not work (it got overwritten on update anyway).

The file seems to be owned by the osmc user

osmc@rpi:~/.kodi/addons/plugin.video.sendtokodi/youtube_dl$ ls -l | grep utils
-rw-r--r-- 1 osmc osmc 125492 feb  4 17:02 utils.py

I also tried changing the addon id in addon.xml, to prevent updates entirely, but that also rendered the addon unusable.

I myself would probably tackle this a different way (Because I don’t know how to do it the way you want). Store a copy of your desired file in a separate location (~/backup or something) and then at regular intervals overwrite the one in .kodi/addons with your stored one, you can automate that with a simple cron job.

1 Like

That’s a good alternative, I didn’t think of that. If there’s no easy way to do it with permissions I might just try that. Thank you.

disable autoupdate and let you just notify and update manually?

1 Like

Autoupdates are already disabled. It is not practical to update every addon manually except one, since there are 100s of them (every single localization in Kodi is listed as an addon) and you only have the choice to update all of them or one at a time.

Auto update can be set per add-on.

This thread has nothing to do with auto updates. They are off.

yeah i know, stupid thought… i don’t know if the packet sources are hashed or something… or where the addons version is stored and compared for an update. maybe you can just increase the local version for several iterations to trick the mechanism into thinking you already have a newer version installed.

1 Like

That’s a new thought! Good idea. I’ll look for a version field…

…it was right next to the id in addon.xml :sweat_smile:

Ingenious. I’ll notice within a week if it works.

Still, if anyone has a way to write protect a single file then I’m still interested since that means I can keep the other files in this addon up-to-date. It uses a bundled version of youtube-dl which sadly needs regular updates.

That trick can break dependencies, as some add-ons require exactly a certain version of another add-on.

Since the youtube_dl add-on is used by your skin and possibly other add-ons, if other add-ons don’t update because they can’t find the right version of youtube_dl, you’ll know it’s the hack you made to increase the version.

But, again, @ActionA had the correct solution…enable auto-updates globally, but then go to the youtube_dl add-on and disable auto-update for it.

as far as i just checked… autoupdate per addon is depended on the developer and only a few have this option?

This is not about the youtube_dl addon, it’s about the sendtokodi addon. It has its own youtube-dl bundled with it.

Enabling auto-updates is of course not the correct solution for someone who doesn’t want auto-updates to be enabled.

Now I’m puzzled. If the problem add-on is sendtokodi, and that has an embedded version of youtube_dl, why do you just want to stop just the embedded youtube_dl files from updating? Since it’s not a separate add-on, then those files are maintained by the sendtokodi maintainer, and are made to work with the add-on. If there is a problem where updating that one file causes problems for you with the sendtokodi add-on, then you should talk to the add-on maintainer and have them fix the issue.

But, that version of the youtube_dl code is not used by any other part of Kodi, as it’s not a separate add-on, so it shouldn’t cause problems outside the sendtokodi add-on.

I wasn’t expecting anyone to be interested in the backstory, but long story short the maintainer will not patch youtube-dl files in his automated weekly build since it would potentially require conflict resolution. Here’s more on that bug.

I wouldn’t mind if someone could convince youtube-dl to not classify it as “not our problem” (I couldn’t), since the Python community hasn’t done anything about the underlying bug for what seems like three years.

It mostly makes me wish addons weren’t written in python.

I’m preventing updates from overwriting my manual patch of the addon.

If the sendtokodi maintainer is just copying the youtube_dl code without wanting making any changes to make it work with his add-on, then why is he copying it? Why not just make it a dependency? The whole point of including the complete code from another add-on is to be able to make changes to it.

I feel for you, in that you like an add-on that isn’t being maintained properly, but it’s not an OSMC issue (or even a Kodi issue), and anything you do to “fix” it will have to be repeated if the add-on gets updated. Since he has a separate repository, I’d just disable that repository if the add-on works for you now, then no update will happen to it.

Since creation is controlled by the directory permissions, you can’t just disable write to a file, because update will likely blow everything away (so that old files don’t remain). And, the directory perms also control delete.

But, you can use file system attributes to protect the single file:

chattr +i utils.py

This command must be run as root.

1 Like

Personally I wasn’t even aware that there was a youtube_dl addon. How often is that one updated? If not weekly then that might explain why, but I don’t know his reasons.

If you have a concrete suggestion to give in the github issue I linked to then I’m sure he’d appreciate it. In my case however I think I should be thankful he does use his own youtube-dl, since that at least isolates my patch to one component.

Yes, this is the problem exactly.

D’oh. I did not think of that. That’s a good way to do it if I can’t lock down this single file.

Oh, right, I didn’t think that one through!

Reading about i and it sounds exactly like what I need :smiley: This would really be as close to ideal as I can get if it works. Hopefully Kodi will just skip the file.

Thanks for all the good suggestions. I’ll work my way through them and see how it goes. I’m glad I asked — I couldn’t seem to think my way through this one myself.