Files opened by "Copy to" get filenames mangled about file_picker_writable HOT 3 CLOSED

I also didn't realize that there is a Copy As with the document APIs on iOS, I thought it would be editable in place.. good to know.

Regarding flags: I think this is pretty similar to persistable - how about reusing it? it's basically the same thing? (It can only be read, and not written back.. and when we implement the proposed fix, we'd delete the file from the Inbox, it is also no longer readable)

I would guess from the name Inbox that we could also delete all of the files, because there shouldn't be any retained files anyway, those are only files which are copied there so they can be imported by the app. But I agree, it would be safer to only delete files we explicitly pass on..

To be honest, I think the file handling is generally a bit wrong right now with many left-over files by default.. Every operation should take a callback within which the caller on the dart side has access to the file, and once the callback returns, the file is always deleted. So for example:

final result = await FilePickerWritable().readFileWithIdentifier(fileIdentifier, (fileInfo, file) async {
  // now we can access `file`
  final contents = await file.readAsString();
  return contents;
});
// now `file` is deleted again.

because the FileInfo.file right now should actually only be read from.. because it is just a copy in most cases (e.g. android content uris, ios urls). but nobody is deleting those files.

I could imagine a similar write operation which takes care of creating a temporary file the caller can use to persist changes..

await FilePickerWritable().writeFileWithIdentifier(fileIdentifier, (file) async {
  // now we can access `file`
  await file.writeString('lorem ipsum);
});
// now `file` is deleted again.

ie. the FileInfo would actually no longer have the file property, but it is only available while inside the callback..

from file_picker_writable.

Regarding flags: I think this is pretty similar to persistable - how about reusing it? it's basically the same thing? (It can only be read, and not written back.. and when we implement the proposed fix, we'd delete the file from the Inbox, it is also no longer readable)

If you're OK with this solution, I do think it's best. I was assuming that because the identifier is technically persistable (it just points to the "wrong" file) that you would prefer persistable: true. But that does violate the spirit and main use case of the plugin.

Actually it turns out you can't write to files in Documents/Inbox, so treating them as non-persistable seems like very much the right choice.

To be honest, I think the file handling is generally a bit wrong right now with many left-over files by default

You are properly using NSTemporaryDirectory to get tmp/; according to the docs:

Use this directory to write temporary files that do not need to persist between launches of your app. Your app should remove files from this directory when they are no longer needed; however, the system may purge this directory when your app is not running.

The contents of this directory are not backed up by iTunes or iCloud.

Since the OS will clean it up I think it's OK to leave them there. Also the user can delete FileInfo.file from Dart if they really want to.

It's just files in Inbox that need additional handling, and I think it's unreasonable to do so from the Dart side.

Every operation should take a callback within which the caller on the dart side has access to the file, and once the callback returns, the file is always deleted

ie. the FileInfo would actually no longer have the file property, but it is only available while inside the callback.

I understand and agree with your desire here, but I have to caution against this kind of API:

• I don't think it's feasible to actually control the lifetime of the file: You can't prevent someone from grabbing it and retaining it within the callback, or adding it to a Stream (in fact one can recreate the old Future-based API fairly easily by doing so). Callbacks may help communicate your intent, but they are also quite painful to work with.

• You can achieve the same delete-on-return semantics with the current API: when the Dart-side MethodChannel call handler returns, the result is fed back to the platform-side. You can delete the file there if you really want.

I will update my PR with:

• persistent: false for Copy-to files
• Deleting Inbox files after return from Dart

from file_picker_writable.

This was addressed by #3

from file_picker_writable.