files without extensions make troubles

[r10s]

the file deduplication from #6265 and #6332 removed all extensions from newly created files.

this causes issues when passing files to the system on iOS, it just does not work.

• preview of images, PDF etc. is not working
• share-from-delta is not working

in both cases, the system only takes a file name (a "url") - and the detection of the file type seem at least partly rely on the extension. if not given, nothing is displayed. see deltachat/deltachat-ios#2524 for system-API links

the only alternative i see, is to copy the file to a temporary file with the correct extension, but that seems to be a waste of power and space, esp. for larger files or slower devices. not to speak of added complexity.

but even if we go that way or find another solution: i have a strong gut feeling that the total removal of extensions is a thing that will bite us also elsewhere, windows (that is much more extension centric than unix), external video player, debugging, whatever.

all other parts, on iOS, work nicely so far, so only displaying not the blob-filename but the real-filename

as the removal of the extension seemed to be also kind of experiment, and @Hocuri already offered to get them back, i think, we should go for that.

[Hocuri]

Then we have to decide whether to keep everything after the leftmost point or everything after the rightmost point. I.e. for archive.tar.xz, do we keep .xz or .tar.xz, and for document.version8.1.pdf, do we keep .pdf or .version8.1.pdf.

Today's code does it differently in different places - suffix() returns only the part after the rightmost point, sanitise_name() employs some heuristics, but tends towards the leftmost point.

Pro leftmost point (plus heuristics like in sanitise_name()):

• No corner cases that don't work, like wanting to open a .tar.xz file.

Pro righmost point:

• All the file extensions explicitly supported by Delta Chat (see guess_msgtype_from_path_suffix()) only have a single point in them
• When passing a file to an external application, the UI anyway needs to set the correct filename by copying it it or otherwise changing the filename (e.g. see DcHelper.java and AttachmentsContentProvider.java in https://github.com/deltachat/deltachat-android/pull/3521/files - though it might well be that that's only possible on Android)
  • If the UI relies on having the "whole" extension when passing to an external app, this might just be hiding the bug
• No weird filenames that won't be deduplicated like hash.version8.1.pdf

cc @link2xt @adbenitez

[r10s]

Pro leftmost point (plus heuristics like in sanitise_name())

this seems sufficient for the things that come to mind, so esp. the "internal or external viewer". it is also what was done in the past and there were no issues with that. if it is easier to do, and has less cornercases, that sounds even more reasonable :)

[link2xt]

I would prefer the rightmost part and no heuristics if we don't need to deal with .tar.gz on iOS. So for received .tar.gz. files they will be stored in <hash>.gz but it should not matter for all usecases iOS has?

[Hocuri]

it is also what was done in the past

Both approaches were taken in different parts of the code.

and there were no issues with that.

There were, so we made the heuristics more complicated to cover more cases, e.g. #6364

if it is easier to do, and has less cornercases

For core, the easier and more straightforward thing to do would be to use the rightmost point, because there are no heuristics which we may have to change in the future. The cornercases when using the rightmost point might be in the UIs, but it depends on how exactly the UIs do things - I can only say that on Android, there wouldn't be any problems.

I'm not against using the leftmost+heuristics, but I do tend to agree with @link2xt and go for rightmost.

[r10s]

but it should not matter for all usecases iOS has?

no, it should be fine for iOS, i am not aware of the preview supporting any of these "double extension file types"

so, if it is simpler i am also for rightmost :)