Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Adapt to file deduplication #2524

Open
6 of 14 tasks
Hocuri opened this issue Jan 16, 2025 · 2 comments
Open
6 of 14 tasks

Adapt to file deduplication #2524

Hocuri opened this issue Jan 16, 2025 · 2 comments
Assignees
Labels
wait-for-core PR/issue is waiting for core release

Comments

@Hocuri
Copy link

Hocuri commented Jan 16, 2025

We want to deduplicate blob files by always setting the file name to be the hash of the file content. Core issue: deltachat/deltachat-core-rust#6265, core PR: deltachat/deltachat-core-rust#6332

To be done:

  • Make sure that the actual name of the file isn't shown to the user or used to determine the file type (via the extension), instead dc_msg_get_filename() (C-FFI) or MessageObject.file_name (JsonRPC) needs to be used, similar to the Android PR at fix: Use getFilename() instead of the actual filename on disk deltachat-android#3521.
    • Search for usages of dc_msg_get_file() (C-FFI) / MessageObject.file (JsonRPC), check where it's passed, and make sure that all it's never used to check the file extension, to pass it to an external application, or to show it to the user.

    • Look at places in the code where a filename is user-visible, like when viewing it in the UI or passing it to an external application (especially when sharing or opening it). Check where the filename comes from, and make sure that it comes from dc_msg_get_filename(), not from dc_msg_get_file().

    • Test that

      • sharing to DC
      • sharing from DC - 🐉 the system preview cannot share files without extension properly, content is not detected, see below
      • opening
      • saving ("Export attachment")
      • drafting and re-entering the chat
      • opening the drafted file once more
      • sending image
      • sending file
      • recording, sending and receiving voice messages (outgoing voice messages still have a .m4a extension)
      • preview - 🐉 the system preview does not show images or PDF without extension, see below

      still works for a) Images b) Videos c) vCards (attached contacts) d) attached files e) webxdc's. Also that editing and previewing drafted images works, and that previewing drafted videos works. (I hope I didn't forget to test any combination)

Then iOS will be ready for using core with deltachat/deltachat-core-rust#6332 merged. Received files will be deduplicated then, but outgoing files not yet.

  • This task depends on File deduplication deltachat-core-rust#6332: For deduplicating outgoing files, similar to File deduplication, Android part deltachat-android#3513, use dc_msg_set_file_and_deduplicate() instead of dc_msg_set_file()
    • Note that you must not write to the files after they were passed to core, because otherwise, the hash will be wrong. So, if iOS recodes videos or so, then the video file can't just be overwritten. What you can do instead is write the recoded video to a file with a random name in the blobdir and then passing the new file to set_file_and_deduplicate().

If all of this becomes too complicated, tell me, we can also decide to put deduplication behind a config or to leave the extension on the deduplicated blobs (e.g. call the file ce940175885d7b78f7b7e9f1396611f.jpg instead of just ce940175885d7b78f7b7e9f1396611f which would make things work with less changes).

@r10s r10s self-assigned this Jan 21, 2025
@r10s
Copy link
Member

r10s commented Jan 21, 2025

we can also decide to put deduplication behind a config or to leave the extension on the deduplicated blobs

it seems we need the extension for the system preview, this is the interface, there is only a "URL" aka "File Name" and a title: https://developer.apple.com/documentation/quicklook/qlpreviewitem - without an extension, no image and no PDF is shown in the preview (the one when you tap an image or PFF and enlarge it)

@Hocuri so, indeed, it would be better to preserver the extension. but as also written elsewhere, even if we can manage that on iOS: 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.

@r10s
Copy link
Member

r10s commented Jan 21, 2025

same for share-from-dc: system's UIActivityViewController takes a URL and no mime or other data and does not detect all types.

however, here, as we want to use the original file name, we probably need to create a copy. but that is far less often than opening a file for detailed viewing

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
wait-for-core PR/issue is waiting for core release
Projects
None yet
Development

No branches or pull requests

2 participants