-
Notifications
You must be signed in to change notification settings - Fork 93
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[develop] Opening exploded archive audiobook inside App Group fails with Publication.OpeningError.unsupportedFormat
in (Designed for iPad) Mac app
#434
Comments
I would expect maybe permission issues to get the children of the directory URLs? But hard to say without debugging. Do you have an error message? |
I don't see any error message, just the |
You could take a look at |
Thanks for the tip! That was what I needed to figure it out. This is failing due to an insane behavior of App Group URLs on MacOS combined with what I think may be an unnecessary behavior in Readium. The insane behavior is that there are apparently two types of App Group URLs. When one calls The possibly unnecessary Readium behavior is that |
Agreed, it looks unnecessary. Feel free to remove the check if that helps with this issue. It is useful when getting an entry though, to make sure we don't request for example |
- let url = url.standardizedFileURL
+ let url = url.standardizedFileURL.resolvingSymlinksInPath() |
I'd prefer to keep it outside the constructor because it will reach the file system and should be asynchronous. In fact, maybe it would be better to keep |
Sure, I can do that if you want. I just thought that |
AFAIK it doesn't need to access the file system to resolve |
Describe the bug
Warning: This is weird.
I am transitioning from normal local URLs created by appending path components to
FileManager.default.url(for: .applicationSupportDirectory, in: .userDomainMask, appropriateFor: nil, create: false)
to app group URLs created by appending path components toFileManager.default.containerURL(forSecurityApplicationGroupIdentifier: APP_GROUP_IDENTIFIER)
but found it broke some of my tests. After some investigation, I found that exploded archive audiobooks fail to open when the directory is in an app group. After some more investigation, I found that it only fails while running on a Mac ( iOS simulator and hardware device work correctly).In other words:
"file:///path/to/dir/file.mp3" -> success
"file:///path/to/dir/"-> success
"file:///AppGroup/path/to/dir/file.mp3" -> success
"file:///AppGroup/path/to/dir/" -> iPadAppOnMacOS ? failure : success
Any idea why this might be happening? If not, I'll work on a reproducible example.
How to reproduce?
Attempt to open a directory of audio files inside an App Group from a Designed for iPad app running on MacOS
Readium version
develop 2fdfea3
OS version
MacOS 14.5
Testing device
MacOS 14.5
Environment
Additional context
No response
The text was updated successfully, but these errors were encountered: