Switch to dc_msg_save_file() for exporting attachments

[iequidoo]

IIUC currently the app implements copying of a file on its own. Also when two files with the same name are sent, the second one gets the name <filename>-1.<ext> and if it's exported then, this mangled name is used. It doesn't look very bad, but i'd suggest to use the original file name, at least when no such file yet exists in the target dir.

[r10s]

ftr, depending on how and if intents are used instead of "just" saving a file, it might be sufficient to use dc_msg_get_filename()

[Hocuri]

It's not possible on Android to write to the Downloads folder using native code (native code is only allowed to write to our own private storage). But DC Android already correctly uses dc_get_filename() and exports the attachment with this name, so this is fine. The -1 gets added when sending (and is also added to Param::Filename then); fixing this will likely need a new core API, so there is nothing Android can do about this at the moment.

[r10s]

instead of a new api: we should be able to write the file to send to a directory outside blobdir, and pass that to core. core will copy the files then to blobdir

i think it is even partly that way for some images from camera

videos-in-creation-to-be-recoded are a bit special, but there, the filename is often not meaningful anyways, so i would regard that separately (or maybe give up that whole on-creation state at some point)

[Hocuri]

instead of a new api: we should be able to write the file to send to a directory outside blobdir, and pass that to core. core will copy the files then to blobdir

If the files then pile up in this directory outside blobdir, eventually there will be name collisions, forcing us to rename files again. And we can't delete them immediately since core only copies them when sending. The good news would be that as far as I can think, there will only ever be one file that needs to be kept there, so the Android code could simply delete the existing file as soon as it needs to pass a new file to core, but still, this seems rather complex to me.

or maybe give up that whole on-creation state at some point

+1

[r10s]

we could create a directory with a random name for every file exported, and delete them after sending (iirc core guarantees that the file is copied in time, needs to be checked). that could be straight forward

[iequidoo]

If deltachat/deltachat-core-rust#5495 is merged, the app can just create a blobdir subdirectory with a random name and put the file there (with the original name) and then pass it to the core. This doesn't require a new core API and that PR also doesn't change it, it only adds support for blobdir subdirs (storing files directly in the blobdir is still possible) and generates random names for these subdirs when copying blobs from external locations. Apps mayn't even follow the core's subdirs name pattern. Also merging that PR doesn't prevent implementing deltachat/deltachat-core-rust#6265 further (EDIT: Moreover, we can use file hashes for subdir names, maybe that will help in implementation). Though of course a huge apps testing is needed before merging, so it's unlikely that happens soon if at all.