[TIMOB-1735] iOS: Blob data returned from File.read becomes empty when the file is deleted
GitHub Issue | n/a |
---|---|
Type | Bug |
Priority | Low |
Status | Closed |
Resolution | Invalid |
Resolution Date | 2017-06-21T21:58:20.000+0000 |
Affected Version/s | Release 3.0.0 |
Fix Version/s | n/a |
Components | iOS |
Labels | api |
Reporter | Brion Vibber |
Assignee | Ingo Muschenetz |
Created | 2011-04-15T03:00:53.000+0000 |
Updated | 2017-06-21T21:58:20.000+0000 |
Description
The File.read method is documented to "return the contents of file as blob":
https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.Filesystem.File.read-method.html"> https://developer.appcelerator.com/apidoc/mobile/latest/Titanium.Fi...
It seems like a reasonable expectation that the returned blob actually contains the data read from the file, however this doesn't appear to be the case; we seem to end up with some sort of indirect reference to the file instead!
If the file is subsequently deleted or altered, our blob also magically empties or changes, contrary to expectations.
Here's some sample code to create a file, read its contents, then delete it. Before deleting it our blob contains the expected amount of data; afterwards its contents appear to have disappeared. (Note that we have to check both .size and .length properties because the undocumented Ti.Blob type has inconsistent APIs between Android and iPhone implementations.)
// Create a temporary file and return its pathname
function buildFile() {
//var tempFile = Ti.Filesystem.createTempFile();
var tempFile = Ti.Filesystem.getFile(
Ti.Filesystem.applicationDataDirectory + '/myfile');
tempFile.write("Hello I am a temp file");
return tempFile.nativePath;
}
// Read the given file's contents into a blob
function readFile(path) {
return Ti.Filesystem.getFile(path).read();
}
function deleteFile(path) {
return Ti.Filesystem.getFile(path).deleteFile();
}
// Create a temporary file and read it in
var path = buildFile();
Ti.API.info("Created temp file " + path);
var blob = readFile(path);
Ti.API.info("We got a blob! It's " + (blob.length || blob.size) + " bytes long");
// We no longer need the temporary file!
Ti.API.info("Deleting " + path);
deleteFile(path);
Ti.API.info("Now our blob is " + (blob.length || blob.size) + " bytes long");
Android:
[INFO] [779,976] Created temp file file:///data/data/net.status.client.quicktest/app_appdata/myfile
[INFO] [290,1266] We got a blob! It's 22 bytes long
[INFO] [2,1268] Deleting file:///data/data/net.status.client.quicktest/app_appdata/myfile
[INFO] [81,1349] Now our blob is null bytes long
iPhone:
[INFO] Created temp file /Users/brion/Library/Application Support/iPhone Simulator/4.0.2/Applications/74ED2286-A5A1-45AF-902F-4FFF2DABFD72/Documents/myfile
[INFO] We got a blob! It's 22 bytes long
[INFO] Deleting /Users/brion/Library/Application Support/iPhone Simulator/4.0.2/Applications/74ED2286-A5A1-45AF-902F-4FFF2DABFD72/Documents/myfile
[INFO] Now our blob is 0 bytes long
If this is intended behavior, it needs to be documented in the docs for File.read; it also should be documented in the docs for the Ti.Blob type (which is conspicuously absent at this time). There also needs to be a clear way added to actually read the current contents of a file, independent of the file's continued existence or contents...
Assigning to our support contact. (Nolan, is there anyone specific we should be assigning bugs in the filesystem area to? Thanks!)
Related issues:
lack of docs for Ti.Blob: https://appcelerator.lighthouseapp.com/projects/32238/tickets/1580-titaniumblob-tiblob-missing-from-mobile-api-documentation"> https://appcelerator.lighthouseapp.com/projects/32238/tickets/1580-...
inconsistent API for Ti.Blob size/length: https://appcelerator.lighthouseapp.com/projects/32238/tickets/1656-api-inconsistency-tiblob-has-length-property-on-android-size-on-ios"> https://appcelerator.lighthouseapp.com/projects/32238/tickets/1656-...
Known filesystem issue. This is a dupe of something but not sure what.
Validated against SDK 2.2.0.014b86f. A consequence of file blobs not being stored in memory.
Closing ticket due to time passed and lack of progress for a number of years. Any problems, please file a new ticket.