You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
In Expo native, I have bundled a series of zip files with my application that are to be unpacked at runtime. These files are expo bundled, provided/loaded as require('my-local.zip') and locally resolved with expo-asset "resolveAsync" which supplies a file:// pointing to a "localUri". In Android, everything works great. In IOS; however, the zip file's localUri resolves to file:///var/mobile/Containers/Data/Application/.../Library/Application%20Support/.expo-internal/... (Note the %20). If you check for this file with expo-file-system FileSystem.getInfoAsync, this file correctly exists and is readable/writeable. If you attempt to unzip this local file uri, it will fail.
If you take this file URI and replace %20 with a space , the zip file correctly unzips as expected. Is it possible that the normalizeFilePath function can check/replace %20 with a space or perhaps do a URI decode on the supplied path? Or should we be doing this ourselves?
Expected behavior
A ZIP file from a URI containing URI encoding on IOS should unzip to the supplied destination.
Environment:
Device: iPad Air 4th gen
OS: iPadOS
OS Version: 16.6
Package Version: 6.0.9
Potential Solution
Adjust the normalizeFilePath as follows:
Describe the bug
In Expo native, I have bundled a series of zip files with my application that are to be unpacked at runtime. These files are expo bundled, provided/loaded as
require('my-local.zip')
and locally resolved with expo-asset "resolveAsync" which supplies a file:// pointing to a "localUri". In Android, everything works great. In IOS; however, the zip file's localUri resolves tofile:///var/mobile/Containers/Data/Application/.../Library/Application%20Support/.expo-internal/...
(Note the %20). If you check for this file with expo-file-systemFileSystem.getInfoAsync
, this file correctly exists and is readable/writeable. If you attempt to unzip this local file uri, it will fail.If you take this file URI and replace
, the zip file correctly unzips as expected. Is it possible that the
%20
with a spacenormalizeFilePath
function can check/replace %20 with a space or perhaps do a URI decode on the supplied path? Or should we be doing this ourselves?Expected behavior
A ZIP file from a URI containing URI encoding on IOS should unzip to the supplied destination.
Environment:
Potential Solution
Adjust the
normalizeFilePath
as follows:Additional context
If we should be providing normalized file uris, can the documentation be updated to indicate this?
The text was updated successfully, but these errors were encountered: