iOS file space retention problem

53 views
Skip to first unread message

Cole Joplin

unread,
May 31, 2012, 4:51:46 PM5/31/12
to byu-cocoaheads
I have a strange iOS problem and wanted to submit it to the group. I
could find anything on StackOverflow.

I have a video file which can get created, not being held in memory.
If I have a reduced space on the device, I want to delete the old file
using [fileManager removeItemAtPath....]; When I check the device with
Organizer, the file is definitely removed, no errors. But when I check
the amount of free space available, it shows no change! Even if I
manually have the button recheck, it's still not changed. If I restart
the app, it sees the change.

Here's how I check the free size:

NSArray *paths =
NSSearchPathForDirectoriesInDomains(NSDocumentDirectory,
NSUserDomainMask, YES);
NSDictionary *dictionary = [filemgr
attributesOfFileSystemForPath:[paths lastObject] error: &error];
NSNumber *freeFileSystemSizeInBytes = [dictionary
objectForKey:NSFileSystemFreeSize]; // technically a uint64_t

Any ideas?

-- Cole

Jeff Bingham

unread,
Jun 1, 2012, 3:35:40 AM6/1/12
to byu-coc...@googlegroups.com, cole....@gmail.com
Sorry Cole, it seems to work fine for me (iPhone 4s, 5.1.1)

How much of your code is when the app starts and how much is on demand (pressing the button)?


I wrote up a quick app to test it.  First entry was when the app started, the second was after I deleted a 30MB file.

freeFileSystemSizeInBytes: 12417998848 Bytes
freeFileSystemSizeInBytes: 12450181120 Bytes


I then moved the [filemgr attributesOfFileSystemForPath:path error:&error] from the button action method into the viewDidLoad method.
In this test, I deleted a 28MB file but it didn't show the change this time.

freeFileSystemSizeInBytes: 12449468416 Bytes
freeFileSystemSizeInBytes: 12449468416 Bytes




-- Cole

--
This was sent to members of the "BYU CocoaHeads" google group.
To post to this group, send email to byu-coc...@googlegroups.com
For our job posting guidelines see http://cocoaheads.byu.edu/wiki/cocoaheads-job-posting-guidelines
To unsubscribe from this group, send email to
byu-cocoahead...@googlegroups.com
Be sure to visit our website at http://cocoaheads.byu.edu

Cole Joplin

unread,
Jun 1, 2012, 11:27:36 AM6/1/12
to byu-coc...@googlegroups.com
When it first loads, it reads it, but there is no delete. The delete is based on a button press only. Very odd that I'm producing the opposite results. I was going to create a test project on it today. If you still have your test project lying around, would you mind sharing? 

Thanks for the input Jeff!

-- Cole

Sent from my iPad

Jeff Bingham

unread,
Jun 1, 2012, 12:38:15 PM6/1/12
to byu-coc...@googlegroups.com
Here is my test file.  I was testing out other options (commented out) that you might want to look into if you can't get this working.

The fileSystemAttributesAtPath method is deprecated but one older site mentioned similar issues that you were getting where attributesOfFileSystemForPath was giving wrong info.

Some SO threads mentioned using statfs and statvfs instead to get the sizes.  the statfs function was giving me the same numbers as fileSystemAttributesAtPath.  statvfs was giving other numbers, between .3 and 3.5 GB instead of the ~12GB I was expecting.  Not sure what is going on there. 

Anyways, I hope this helps.
statvfs.zip

Cole Joplin

unread,
Jun 4, 2012, 11:59:10 AM6/4/12
to byu-coc...@googlegroups.com
Thanks, Jeff. I discovered two things. One big problem I resolved was
I had a video preview that had the file loaded, but this was only if
you had actually gone to the popup with the preview on it. Even with
that fixed, when the free size was under 1GB, we sometimes had the
wrong number, but it was hard to recreate. After some more Googling, I
wasn't alone, especially under the 1GB mark, suggesting it's just not
100%. In the app, this would only occur in a very extreme case of low
capacity, and it's manageable.

Thanks again, Jeff!

-- Cole
Reply all
Reply to author
Forward
0 new messages