Debugging Delta issues with BinaryDelta apply

[aprilnoren]

Hello,

We have recently added support for delta updates via Sparkle and we are on version 1.27.0 ( Updating to v2.x is still on the backlog ). During testing I noticed that my delta will not patch correctly. I ran the BinaryDelta apply to it and get:

BinaryDelta: failed to write new file: blah.pdf: Permission denied
Unable to patch /old/blah.pdf to destination /new/blah.pdf

I have looked into and discovered a few things:

• The blah.pdf has read-only permissions in the bundle
• The blah.pdf had read/write permissions in the repo
• The file is localized and copied into the bundle via Copy Bundle Resources in Xcode.
• 2 of the 6 localized blah.pdf files get read-only permissions when copied but the others do not.

❓ How can I still deliver a delta update with this one file causing an issue?
❓ Is there a way to ignore this file when creating/applying the delta?
❓ Any idea why Xcode is changing the permission of my file?

• ❗ I have thought of trying to force the permissions to r/w after copy but I think that will cause an issue with signing

❓ Are there changes in newer versions of Sparkle 1.x or 2.x that would give me more options in solving this problem?

Thanks for your time,
April

[zorgiepoo]

The blah.pdf has read-only permissions in the bundle

I suggest you should investigate why this is happening. I include several pdf's in my app's Resources for example and they're all 0644.

The blah.pdf has read-only permissions in the bundle

git will only store file permissions 0644 or 0755 for regular files and I believe BinaryDelta warns when other permission modes are encountered.

The file is localized and copied into the bundle via Copy Bundle Resources in Xcode
2 of the 6 localized blah.pdf files get read-only permissions when copied but the others do not.

How are the files localized? Maybe the tool or process that's doing the localization is the cause of the permissions changing. I doubt Xcode is responsible for the change, but if it is then I suggest filing a feedback report issue to Xcode. Xcode's full build log may give you some insight.

❗ I have thought of trying to force the permissions to r/w after copy but I think that will cause an issue with signing

I suggest doing this as a workaround, if you cannot find the root cause of the issue. Code signing is not a problem. If you add a Run Script phase in Xcode after your copy phase that alters files in your produced app bundle, that phase will be run before Xcode signs your app bundle. (Also code signing doesn't validate file permissions).

Are there changes in newer versions of Sparkle 1.x or 2.x that would give me more options in solving this problem?

2.1 onwards introduced a new and improved container/archive format for delta updates, but this bit of logic has stayed the same. It is actually a sort of optimization / simple case which opens the existing file in write mode instead of stat'ing the old file and applying new permissions after the patch. I don't think I want to change it unless this proves to be more widespread. Maybe I should even add a check during patch creation requiring all regular files to be writeable.. (we used to have it that we would reject permissions like this but relaxed the restriction a bit).
_

[zorgiepoo]

I changed my mind. I can fix this in future versions of Sparkle. #2211. Until then you'll need to find the permission-change cause or work around it.

[aprilnoren]

Thanks for the detailed response. I will look into adding a Run Script phase until we can figure out why this is happening to this file or update to Sparkle 2.x with your change.