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

Saving a file to storage by sharing it causes loss of file name and extension #37

Open
6 tasks done
luewolf opened this issue Jan 23, 2024 · 4 comments · May be fixed by #86
Open
6 tasks done

Saving a file to storage by sharing it causes loss of file name and extension #37

luewolf opened this issue Jan 23, 2024 · 4 comments · May be fixed by #86
Labels
bug Something is not working

Comments

@luewolf
Copy link

luewolf commented Jan 23, 2024

Checklist

  • I can reproduce the bug with the latest version.
  • I made sure that there are no existing issues - open or closed - to which I could contribute my information to.
  • I have read the FAQ and my problem isn't listed.
  • I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
  • This issue contains only one bug.
  • I have read and understood the contribution guidelines.

Describe the bug

When sharing a single file that isn't a directory from any app, the file manager can be selected as destination to save the file in shared storage. However, both the file name and extension are lost when saving the file. The loss of the file extension in particular means that other programs (i.e. those that only have permissions for media files) won't be able to discover/open the file.

To Reproduce

Steps to reproduce the behavior:

  1. Go to any app that allows sharing a single file. The file manager itself will do. Open the share dialog.
  2. Look for the destination titled "File Manager", subtitle "Save..." and click on it.
  3. Select a directory to save the file at.
  4. In file manager, navigate to that directory. The file will be titled something like "1000019000" now. It will not have a file extension.

Expected behavior

Ideally, the file would keep its name and extension.

If the sharing API simply does not provide this info, file extensions can be "guessed" using a file format's magic number. This should be implemented for common file formats like zip, pdf, png, jpg, webp, gif, mp3, mp4, ogg.

@luewolf luewolf added bug Something is not working needs triage Issue is not yet ready for PR authors to take up labels Jan 23, 2024
@Aga-C Aga-C removed the needs triage Issue is not yet ready for PR authors to take up label Jan 23, 2024
@tom93
Copy link
Contributor

tom93 commented Jan 26, 2024

Hi devs, would you like help with this?

It seems reasonably straightforward -- modify SaveAsActivity.kt to call contentResolver.query(source, ...) and look up the relevant columns (I think MediaStore.MediaColumns.DISPLAY_NAME, and fall back to DATA; also MIME_TYPE). I'm happy to write a PR.

@Aga-C
Copy link
Member

Aga-C commented Jan 26, 2024

I'm happy to write a PR.

@tom93 When there's no needs triage label on an issue, you're free to create a PR solving it.

@matkoniecz
Copy link

@tom93 Are you still planning to make a PR?

tom93 added a commit to tom93/FossifyOrg-File-Manager that referenced this issue Apr 20, 2024
Previously, the code used the last path component of the content URI,
but that isn't necessarily the filename -- it can be a numeric ID.

Switch to the helper function getFilenameFromContentUri(), which uses
ContentResolver to read the DISPLAY_NAME column. (If that fails, we
fall back to the last component of the content URI as before, because
we don't have anything better to use.)

Also improve the way the MIME type is determined. Previously it was
just based on the file extension. Switch to first query the
ContentResolver, then try the type of the Intent (which is supposed to
be set to the MIME type of the data for ACTION_SEND, but may be set to
"*/*" if the type is unknown), and only then fall back to using the
file extension.

Fixes FossifyOrg#37.
@tom93 tom93 linked a pull request Apr 20, 2024 that will close this issue
4 tasks
@tom93
Copy link
Contributor

tom93 commented Apr 20, 2024

@matkoniecz I've been putting it off, but your message gave me the push I needed and I finally made PR #86 :)
For people who want to test my fix without building from source, I've built an APK with the patch from my PR plus this patch which adds some debugging logs, but note that I am not a project member so you shouldn't trust me:
unofficial-file-manager-pr-86-with-debug.apk.zip
To view the debug logs, run adb logcat and search for lines containing "XXX".

In the end I didn't implement the fallback to the DATA column, because the DISPLAY_NAME column worked in all my tests (and there was existing code for reading the DISPLAY_NAME column).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something is not working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants