Upload process creates local copies, adds '.' prefix, and requires re-download for local files

[Andzhouyushu]

⚠️ Before posting ⚠️

• This is a bug, not a question or an enhancement.
• I've searched for similar issues and didn't find a duplicate.
• I've written a clear and descriptive title for this issue, not just "Bug" or "Crash".
• I agree to follow Nextcloud's Code of Conduct.

Steps to reproduce

⚠️ Before posting

• This is a bug, not a question or an enhancement.
• I've searched for similar issues and didn't find a duplicate.
• I've written a clear and descriptive title.

Description

This is a serious design flaw in the Nextcloud Android client's upload logic. It manifests as three interconnected problems that severely impact user experience, especially for photo backups.

Steps to reproduce

1. Open the Nextcloud Android app.
2. Upload any image from /DCIM/ or /Pictures/ (via Auto-Upload or manual upload).
3. Observe the local file system before, during, and after upload.
4. Try to view the uploaded file in the system gallery.

Actual behaviour

Issue 1: Unnecessary local copy

• Regardless of "Move", "Keep", or "Delete" settings, the app always creates a local copy in its private directory (e.g., Android/media/com.nextcloud.client/ or Android/data/com.nextcloud.client/).
• This effectively doubles the storage usage for every uploaded photo.
• The "Move" option does not truly move — it copies to private directory, then deletes the source, but the private copy remains permanently.

Issue 2: Files are prefixed with '.' making them invisible to system gallery

• During upload (or after failed cleanup), the source file may be renamed with a . prefix (e.g., IMG_001.jpg → .IMG_001.jpg).
• On Android/Linux, files starting with . are treated as hidden.
• The system MediaStore (Gallery) ignores all hidden files, so photos disappear from the user's gallery.
• Even if the file is intact, the user cannot see it in any gallery app.

Issue 3: Local file requires cloud re-download for export ("Export" = cloud download)

• When the user taps "Export" to recover the file to a visible location (e.g., /Download/), the app downloads the file from the cloud — even though the file is already present on the device.
• This is absurd: a file that exists locally (in the private directory) cannot be "exported" without re-downloading.
• This wastes mobile data and time, especially for large files.

Expected behaviour

期望行为

1. 直接上传：App 应直接从源位置读取文件流并上传至服务器。
2. 无需不必要的副本：App 不应在私有目录中创建本地副本；如果出于后台续传考虑必须创建，则在上传成功后应立即删除。
3. 保留文件名：App 不应在任何情况下给文件添加 . 前缀。
4. 真正的本地导出：“导出”功能应直接将已有的本地文件移动/复制到目标位置，无需从云端重新下载。

Actual behaviour

Expected behaviour

1. Direct upload: The app should read the file stream directly from its source location and upload to the server.
2. No unnecessary copy: The app should NOT create a local copy in a private directory, or if it must (for background upload), it should delete the copy immediately after successful upload.
3. Preserve filename: The app should NOT add . prefix to any file, regardless of upload state.
4. True local export: The "Export" function should simply move/copy the existing local file to the target location without re-downloading from the cloud

Android version

17

Device brand and model

REDMI K90 PRO MAX

Stock or custom OS?

Stock

Nextcloud android app version

34.1.0

Nextcloud server version

34.0.3

Using a reverse proxy?

No

Android logs

Why this matters

• Photos are the most common upload type, and this bug makes the app unsuitable for photo backups.
• Users are forced to use third-party tools (FolderSync, Syncthing) for backups, defeating the purpose of having a first-party Nextcloud client.
• The current behavior wastes storage (Issue 1), breaks gallery integration (Issue 2), and wastes bandwidth/battery (Issue 3).

Suggested fix

1. Use ContentResolver.openInputStream() to read files directly from MediaStore and upload via streaming — no local copy needed.
2. For background uploads where a local copy is technically required, implement a cleanup mechanism that deletes the copy immediately after successful upload.
3. Never modify the source filename. Use separate temp files in the private directory, but never rename the source.
4. For "Export", check if the file already exists locally in the app's private directory. If yes, move/copy it directly without cloud download

Additional references

• Related user discussions confirm this is a widespread issue.
• This bug has existed for years and affects thousands of users.

Thank you for maintaining this project. Please prioritize this issue — it makes the app nearly unusable for its primary use case (photo backup).

Server error logs

Additional information

No response

[daniele-verducci]

Hello @Andzhouyushu ,
thanks for your report.
I thoroughly tested the functionalities, but was not able to reproduce the reported issues, unfortunately.

I'll try to answer point by point, maybe this can help to pinpoint the issues and find what's an issue and what's by design.

Issue 1: Unnecessary local copy

• In case of Move: the file is moved to the nextcloud internal folder, and that's by design. The filename is not changed, but if you enabled the "Use subfolders" option, it will obey to that one and place the image in a subfolder. I could see the image in the device gallery.
• In case of Delete: the file is deleted. It is no more on the device, so it's not visible in the device gallery, because it does not exist.
• In case of Keep: the file is left where it is, and is visible in the gallery.

Issue 2: Files are prefixed with '.' making them invisible to system gallery

In none of the previous cases the filename has been changed (no dot before the name). If this is a bug, it may happen in determinate conditions, can you share a way to reproduce it consistently?

Issue 3: Local file requires cloud re-download for export ("Export" = cloud download)

That is not the case for a file already present on the device (i.e. if the autoupload was set to Move or Keep), but it will happen if the file it's not present (i.e. autoupload was set to Delete or the file was deleted from the app choosing "Local only" option in the deletion modal).

About the additional references, can you please link some of these? They may contain useful details.