feat: Make dc_msg_get_filename() return the original attachment filename (#4309)

[iequidoo]

No description provided.

[link2xt]

This does not look good for usablity, because these filenames are visible in the UI when you save the file.

See discussion at related issue #3817.

[link2xt]

This branch now mixes new API and adding random filenames which makes things worse for Desktop if we merge this as is without modifying the UI code.

@iequidoo Could you create a separate branch/PR on top of stable that does only this:

1. Save original attachment filename to the param.
2. Display this original filename in the message info.
3. Change Message.get_filename() to return the original filename rather than the basename of the file stored in the blobdir. This will be automatically accessible in JSON-RPC via this field so there is no need to change anything on the JSON-RPC side:

   deltachat-core-rust/deltachat-jsonrpc/src/api/types/message.rs

   Line 79 in f930576

   file_name: Option<String>,

4. Add C API dc_msg_get_filename, Python API and a Python test that checks that when the same file is sent twice, two messages arrive and both of them have the original unmangled attachment filename accessible via this API.

These changes do not require any research and discussion and would be easy to merge into the stable branch, but combined with deltachat/deltachat-desktop#3330 will already improve the situation with a common use case of saving PDFs, .xdcs through the Save As dialog and similar documents which need to be sorted out rather than opened in a viewer.

[link2xt]

I am not sure yet that we can get rid of this API on Android. Android UI offers an "Export attachments" action, which creates an external storage filename (actually an Android.net.Uri) using Java API and then copies the file contents from the path provided by dc_msg_get_file to the new path. Android storage is complicated with many possibilities and compatibility questions: https://developer.android.com/training/data-storage/shared

For now I would say this is not deprecated, this API is still good for providing access to the file contents, but the first line of description can be changed to remove "file name and extension of the file" and say that filename with extension should be queried using a new API dc_msg_get_filename that returns an email attachment filename rather than a filesystem path. So C API needs a dc_msg_get_fliename as well, then on Android it will be a minor change to use this API to get the filename and extension and only use dc_msg_get_file to access the file contents.

cc @r10s, also would be nice if you can look into iOS code and check what kind of API is needed there.

[r10s]

to me, the gist of this pr is not totally clear, however, i also did not follow all recent discussions around it.

yip, get_file() is used on iOS as well - and probably also for deltatouch and desktop. i do not see how save_file() can be a good replacement for it, eg. most files are images where you do not even see the filename, it does not make sense to copy them around all the time, it is totally fine to access them directly.

the files returned from get_file should also provide the correct extensions, eg. there are internal viewers etc., i am pretty sure we will break things, if we have extensionless blobs here and try to access them. the filename, however, can be random, and yes, we should not use get_file() function to get correct filename and extension. (just to clarify, i assume, this was what @link2xt meant)

things are only different for "documents", where you want to display the correct filename, so a get_filename() makes sense. if a save_file() is really helpful then, not sure, these things are pretty OS-specific and copying a file from get_file() to "somepath" + get_filename() is easy, if needed that way - in practise, OS will require more complicated export things

[iequidoo]

At least it simplifies the code a bit in deltachat-jsonrpc/src/api/mod.rs:misc_save_sticker(). Removed from this PR, will add later in the master, then we can rediscuss it

[iequidoo]

@iequidoo Could you create a separate branch/PR on top of stable that does only this:

1. Save original attachment filename to the param.

2. Display this original filename in the message info.

3. Change `Message.get_filename()` to return the original filename rather than the basename of the file stored in the blobdir. This will be automatically accessible in JSON-RPC via this field so there is no need to change anything on the JSON-RPC side: https://github.com/deltachat/deltachat-core-rust/blob/f930576fd1a2feef981cbaa2e691f52bb66d2582/deltachat-jsonrpc/src/api/types/message.rs#L79

4. Add C API `dc_msg_get_filename`, Python API and a Python test that checks that when the same file is sent twice, two messages arrive and both of them have the original unmangled attachment filename accessible via this API.

These changes do not require any research and discussion and would be easy to merge into the stable branch, but combined with deltachat/deltachat-desktop#3330 will already improve the situation with a common use case of saving PDFs, .xdcs through the Save As dialog and similar documents which need to be sorted out rather than opened in a viewer.

@link2xt, done but instead of adding a Python test i just extended test_long_filenames(). dc_msg_get_filename() maps 1-1 to the corresponding Rust function, so i think having a Rust test is sufficient.

[link2xt]

These changes and most of the discussion on the PR are unrelated now, this is why I suggested opening a new branch and PR instead, but ok.