PFFile Directories Need Clean Up

[joshbeal]

Users of my app have complained about it taking up too much space on disk. Inspecting the app bundle reveals two large directories maintained by Parse.

• Private Documents / Parse / PFFileStaging (600+ MB)
• Caches / Parse / PFFileCache (40+ MB)

I find it odd that Parse is not cleaning those up. I also don't understand why it is loading files in PFFileStaging at all since I'm using a regular networking library to load the files from URL.

I've observed these issues on V1.7.4 but I have no reason yet to believe they've been fixed in later releases. Any thoughts?

[richardjrossiii]

PFFileStaging is done so that we can ensure that no concurrent modification happens to the file after you request uploading. However, we should be moving, after upload, all files from PFFileStaging to PFFileCache, unless the upload is interrupted/fails. See PFFileController.m.

Can we get a small repro case?

[nlutsenko]

What I think should happen is:

• we should have an explicit way to cleanup all the caches for PFFiles (aka delete Caches/Parse/PFFileCache)
• automatically trim the staging directory when the file isn't references anymore, like after an app restart.

[richardjrossiii]

Agreed on clearing the staging directory upon parse initialization. Not so sure a public API for clearing the cache is useful, but we can add it.

[joshbeal]

+1 for automatically trimming the staging directory. it would be nice to have that done in background to avoid blocking app launch.

[nlutsenko]

Hey guys, a quick update... we are tracking this for version 1.8.2 and will get there very soon.

Our current plan is to implement automatic nuking for Private Documents/PFFileStaging directory on every app restart. That directory is not automatically cleared by the system, so this is quite relevant to do.

In regards to File Cache under Caches/Parse/PFFileCache - that one is guaranteed to be cleared automatically by the system whenever the device is low on disk space, so manually clearing cache there is not necessary.