[go: up one dir, main page]

Skip to content
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

New Location for the LevelDB directory #843

Closed
DiogoAndre opened this issue Feb 23, 2018 · 9 comments · Fixed by #4609
Closed

New Location for the LevelDB directory #843

DiogoAndre opened this issue Feb 23, 2018 · 9 comments · Fixed by #4609
Assignees

Comments

@DiogoAndre
Copy link
  • Xcode version: 9.2 (9C40b)
  • Firebase SDK version: 4.0.15
  • Firebase Component: Firestore
  • Component version: 0.10.1

Describe the problem

Firestore is currently storing the LevelDB files under the Documents/ directory on iOS. The Documents/ directory is visible to the end user (i.e in the Files app) and this could cause issues if an user inadvertently delete or rename a file belonging to Firestore/LevelDB.

Steps to reproduce:

  1. Create a basic iOS project with Firebase and Firestore
  2. Add the LSSupportsOpeningDocumentsInPlace and UIFileSharingEnabled to the project info.plist
  3. Run the project in Simulator
  4. Cmnd+H and open the Files app
  5. A folder named after the App should be present under 'On my iPhone'.
  6. If a filter is not visible, go to Photos app, chose an image and hit the 'Share' button. Swipe until 'Save on Files' is visible and chose it. The new folder should appear there.

Proposed Change:

I propose we change the location for the LevelDB directory from Documents/ to Library/Application support. This location is more inline with the guidelines defined by Apple here

Relevant bits:

  • Put user data in Documents/. User data generally includes any files you might want to expose to the user—anything you might want the user to create, import, delete or edit. For a drawing app, user data includes any graphic files the user might create. For a text editor, it includes the text files. Video and audio apps may even include files that the user has downloaded to watch or listen to later.
  • Put app-created support files in the Library/Application support/ directory. In general, this directory includes files that the app uses to run but that should remain hidden from the user. This directory can also include data files, configuration files, templates and modified versions of resources loaded from the app bundle.
  • Remember that files in Documents/ and Application Support/ are backed up by default. You can exclude files from the backup by calling -[NSURL setResourceValue:forKey:error:] using the NSURLIsExcludedFromBackupKey key. Any file that can be re-created or downloaded must be excluded from the backup. This is particularly important for large media files. If your application downloads video or audio files, make sure they are not included in the backup.
@wilhuff
Copy link
Contributor
wilhuff commented Feb 23, 2018

This location is essentially based on where we did it in the RTDB and that location was chosen somewhat arbitrarily. This is user data, but agreed that it's not user data that's useful as individual files. Regardless of our philosophical position on it the end-user experience with LSSupportsOpeningDocumentsInPlace and UIFileSharingEnabled enabled is something we should fix.

@mathieugarcia
Copy link

We provide custom directory browsing within our app. Until the fix is rolled out, I will have to manually hide this directory to the user.

@triplef
Copy link
triplef commented Dec 6, 2018

+1

@mathieugarcia can you share how you are hiding the directory? We tried setting NSURLIsHiddenKey but it’s still showing in Files app.

@rupertdaniel
Copy link

It would be great if this issue could be addressed. Our users make use of the Files app to transfer a lot of files in/out of the device/app. This folder causes confusion to some people and is at risk of being deleted by the user.

@harrygt
Copy link
harrygt commented Jan 24, 2019

Definitely agree here. User's shouldn't be able to access this in the Documents directory which is meant for User generated files.

@iwikal
Copy link
iwikal commented May 2, 2019

@wilhuff is on the roadmap?

@wilhuff
Copy link
Contributor
wilhuff commented May 3, 2019

For sure, though the fix is tricky when accounting for migrating existing data because we're not structured to handle that (yet).

@fawzialrifai
Copy link

@mathieugarcia how can I hide Firebase directory please?

wilhuff added a commit that referenced this issue Jan 17, 2020
This moves iOS and macOS user data from `NSDocumentDirectory` to `NSApplicationSupportDirectory`, adding a pre-open migration step that:

  * Moves old data into the new location
  * Cleans up any resulting empty directories in the old Documents folder
  * Stops before removing the Documents folder itself (see tests)

Note that other platforms don't need a migration:

  * tvOS was already storing documents in `NSCachesDirectory`
  * Linux, Windows, and other UNIX haven't been publicly released or aren't changing.

See individual commits for details. Most notably this adds some additional filesystem manipulation routines to our (sadly) growing library.

Fixes #843.
@wilhuff
Copy link
Contributor
wilhuff commented Jan 17, 2020

This will go out with the next release!

@firebase firebase locked and limited conversation to collaborators Feb 16, 2020
ryanwilson pushed a commit that referenced this issue Apr 24, 2020
This moves iOS and macOS user data from `NSDocumentDirectory` to `NSApplicationSupportDirectory`, adding a pre-open migration step that:

  * Moves old data into the new location
  * Cleans up any resulting empty directories in the old Documents folder
  * Stops before removing the Documents folder itself (see tests)

Note that other platforms don't need a migration:

  * tvOS was already storing documents in `NSCachesDirectory`
  * Linux, Windows, and other UNIX haven't been publicly released or aren't changing.

See individual commits for details. Most notably this adds some additional filesystem manipulation routines to our (sadly) growing library.

Fixes #843.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
8 participants