breautek commented on issue #646: URL: https://github.com/apache/cordova-plugin-file/issues/646#issuecomment-2625705474
**IF** `externalDataDirectory` is actually null, then it would be the first time I've ever heard of it being null if I were to be honest. I thought all modern devices emulate external storage if there is no actual physical removable mediums present. So it is still weird. > What do you recommend I use so its internal to the device...not external? And switching to internal memory, on the app, I believe it wouldn't change the behavior...its still an internal directory to the app that the user can't physically get to, just a different location right? I don't know if I can answer that because it would depend on your own use case but I can give information. Historically the `internal` storage is a partition that is fixed on device, and `external` storage was always removable disk, such as a SD card. It was recommended to use external storage when possible since the internal storage capacity was limited. At some point, devices started to emulate SD cards for devices that lack them, or simply don't have a SD card, probably for app compatibility reasons. **Today**, in my personal experience, using internal storage is fine unless if you have some use cases that involves sharing files. I exclusively use internal storage in my apps, storing large log files without issue or complaints. > just a different location right? `dataDirectory` is the internal storage version of `externalDataDirectory` and yes it is a different. Internal storage is "more" private than external storage. While `externalDataDirectory` is still app-specific, users can pull files by removing the sd card and inserting it on a PC or whatever. The internal app-specific data directory is only accessible by your own application. Changing to use `dataDirectory` means you'll need a migration strategy for your existing app users. > I believe it wouldn't change the behavior There are some behaviour changes between internal and external storage since API 29 / Scoped Access Framework introduction. I can't remember on top of my head if SAF restrictions apply to app-specific external directories however, so behaviour differences might not apply to you here. SAF restrictions do not apply to internal storage. > I wish Android did file systems the way iOS does. On iOS my app shows up as a folder in the users public "downloads" folder, its just symlink to the real folder embedded within my app directory structure. Clean and simple. The android equivalent folder for this would be `externalRootDirectory + "Downloads/` (we don't have a constant for the downloads directory), however the file plugin read/write access to this will be limited due to SAF restrictions. SAF restricts direct access via the native File APIs, so to modify many parts of the external filesystem requires using the MediaStore APIs, which the File plugin does not (and likely won't) implement. MediaStore APIs is not very "filesystem-like" so it's not very feasible trying to interface with it from a "filesytem" api perspective. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@cordova.apache.org For additional commands, e-mail: issues-h...@cordova.apache.org
