3

I have an app that is using NSFileWrapper to create a backup of the user's data. This backup file contains text and media files (compression is not relevant here). Sometimes these backup files get quite large, over 200 MB in size. When I call NSFileWrapper -writeToURL... it appears to load the entire contents into memory as part of the writing process. On older devices, this causes my app to be terminated by the system due to memory constraints.

Is there a simple way to avoid having NSFileWrapper load everything into memory? I've read through every NSFileWrapper question on here that I could find. Any suggestions on how to tackle this?

Here is the current file structure of the backup file:

BackupContents.backupxyz user.txt - folder1 - audio files asdf.caf asdf2.caf - folder2 - audio files asdf3.caf

Again, please don't tell me to compress my audio files. That would only be a band-aid to a flawed design.

It seems like I could just move/copy all of the files into a directory using NSFileManager and then make that directory a package. Should I go down that path?

Mark Suman
  • 10,430
  • 2
  • 27
  • 23

1 Answers1

3

When an NSFileWrapper tree gets written out to disk, it will attempt to perform a hard-link of the original file to the the new location, but only if you supply a parameter for the originalContentsURL.

It sounds like you're constructing the file wrapper programmatically (for the backup scenario), so your files are probably scattered all over the filesystem. This would mean that when you writeToURL, you don't have an originalContentsURL. This means the hard-link logic is going to get skipped, and the file will get loaded so it can get rewritten.

So, if you want the hard-linking behavior, you need to find a way to provide an originalContentsURL. This is most easily done by supplying an appropriate URL to the initial writeToURL call.

Alternatively, you could try subclassing NSFileWrapper for regular files, and giving them an NSURL that they internally hang on to. You'd need to override writeToURL to pass this new URL up to super, but that URL should be enough to trigger the hard-link code. You'd want to then use this subclass of NSFileWrapper for the large files you want hard-linked in to place.

Dave DeLong
  • 242,470
  • 58
  • 448
  • 498
  • Coincidentally, I was able to fix my problem by simply providing my app's `NSDocumentDirectory` as the `originalContentsURL` on `writeToURL...`. That works in this instance because all of my children file wrappers point to items within that directory. However, this answer is more robust as it handles my situation while also handling the situation where you are pulling files from directories with different ancestry. – Mark Suman Jun 19 '15 at 18:02