Skip to content

Conversation

@zerox80
Copy link
Contributor

@zerox80 zerox80 commented Jan 10, 2026

Download and Sync Feature

Summary

This PR adds the ability to download all files from the server and keep them synchronized locally. Users can now enable offline access for their entire account through the settings.

Changes

External Storage with Human-Readable Folder Names

  • Files are now stored in External storage with clear, readable folder names
  • Improved file organization for better user experience

Sync Option and Download All Files

  • Added new sync settings in the Security/Privacy section
  • Implemented DownloadEverythingWorker to handle bulk downloads
  • Implemented LocalFileSyncWorker to keep local files in sync with the server
  • Users can enable/disable the sync feature through settings

Worker Improvements

  • Fixed DownloadEverythingWorker to properly iterate through all folders and files
  • Improved error handling and progress reporting
  • Added proper recursive folder traversal

Localization

  • Changed German storage permission dialog text to English for consistency

Testing

  • Tested download of multiple files and folders
  • Verified sync worker runs correctly in the background
  • Confirmed files are stored in the correct external storage location

Related Issues

#24

zerox80 added 4 commits January 10, 2026 12:13
- Switch to External Storage Directory in ScopedStorageProvider.
- Request MANAGE_EXTERNAL_STORAGE permission on Android R+.
- Use Space names instead of IDs for folder structure.
- Rename data folder to OpenCloud.
…iles

- Root cause: refreshFolder() only returned changed files, not all
- Solution: Use getFolderContent(folderId) after refresh to get ALL files from DB
- Add recursive folder traversal with proper refresh before each folder scan
- Improve LocalFileSyncWorker with better statistics and notifications
- Remove setForegroundAsync to fix Android 14+ foreground service crash
@zerox80 zerox80 force-pushed the feature/download-sync branch from 187f570 to 0f69672 Compare January 10, 2026 11:13
@samolego
Copy link

This is a killer feature!
Question: what happens on file conflicts, e.g. if file is edited on web and on the device? How is synchronization handled?

Also, how does background sync work in regards of battery management in Android?

zerox80 added 2 commits January 11, 2026 21:03
Changed avatar endpoint from legacy /index.php/avatar/ to
/graph/v1.0/me/photo/ for openCloud compatibility.
When a file changes both locally and remotely, automatically upload
the local version instead of requiring manual conflict resolution.
This provides a seamless auto-sync experience (last write wins).
@zerox80
Copy link
Contributor Author

zerox80 commented Jan 12, 2026

This is a killer feature! Question: what happens on file conflicts, e.g. if file is edited on web and on the device? How is synchronization handled?

Also, how does background sync work in regards of battery management in Android?

When a file changes both locally and remotely, automatically upload
the local version instead of requiring manual conflict resolution.
This provides a seamless auto-sync experience (last write wins).

https://github.com/zerox80/android/releases

@samolego
Copy link

When a file changes both locally and remotely, automatically upload
the local version instead of requiring manual conflict resolution.
This provides a seamless auto-sync experience (last write wins).

I don't think that's the best way to handle this. Desktop version pulls the file on conflict and names it _conflicted_copy or sth. similar.

I think we shouldn't be overwriting remote work, at least not without user confirmation.

if (!android.os.Environment.isExternalStorageManager()) {
val builder = AlertDialog.Builder(this)
builder.setTitle(getString(R.string.app_name))
builder.setMessage("To save offline files, the app needs access to all files.")

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This strings should probably be translated

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, can do micro patch later

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lets have focus on implementing the sync stuff perfectly, translation etc can be done later

<string name="db_file" formatted="false">opencloud.db</string>
<string name="db_name" formatted="false">OpenCloud</string>
<string name="data_folder" formatted="false">opencloud</string>
<string name="data_folder" formatted="false">OpenCloud</string>

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this necesarry?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

looks better

@zerox80
Copy link
Contributor Author

zerox80 commented Jan 12, 2026

When a file changes both locally and remotely, automatically upload
the local version instead of requiring manual conflict resolution.
This provides a seamless auto-sync experience (last write wins).

I don't think that's the best way to handle this. Desktop version pulls the file on conflict and names it _conflicted_copy or sth. similar.

I think we shouldn't be overwriting remote work, at least not without user confirmation.

But whats issue with last write win strategy? The manual user interaction is really bad UX, the Sync before that sync rework worked, but showed conflict. Its just very very unlikely that it will become an issue. The overwrite happens only if i change the file and save it. I think UX should imo have more priority, cuz thats a ~1% chance that it causes issues

@zerox80
Copy link
Contributor Author

zerox80 commented Jan 12, 2026

When a file changes both locally and remotely, automatically upload
the local version instead of requiring manual conflict resolution.
This provides a seamless auto-sync experience (last write wins).

I don't think that's the best way to handle this. Desktop version pulls the file on conflict and names it _conflicted_copy or sth. similar.
I think we shouldn't be overwriting remote work, at least not without user confirmation.

But whats issue with last write win strategy? The manual user interaction is really bad UX, the Sync before that sync rework worked, but showed conflict. Its just very very unlikely that it will become an issue. The overwrite happens only if i change the file and save it. I think UX should imo have more priority, cuz thats a ~1% chance that it causes issues

So should we just add the conflict stuff again with a easy option "last write win" ? how should it be solved without causing a really really bad UX?

@zerox80
Copy link
Contributor Author

zerox80 commented Jan 12, 2026

This is a killer feature! Question: what happens on file conflicts, e.g. if file is edited on web and on the device? How is synchronization handled?

Also, how does background sync work in regards of battery management in Android?

Have to test it, but i didn't have both open at same time. I only tested editing something, closing on web, editing 2 seconds later on Android. I planned to test that scenario today

@zerox80
Copy link
Contributor Author

zerox80 commented Jan 12, 2026

@samolego
You're right that data safety should be prioritized. I'll implement a conflicted copy approach similar to the desktop version:

When both local and remote have changed, download the remote version AND keep the local file renamed as filename_conflicted_copy_.ext
This ensures no data loss while still avoiding manual intervention
The user can then compare and decide which version to keep

zerox80 added 5 commits January 12, 2026 16:46
…e is modified both locally and remotely, create a conflicted copy of the local file and download the remote version. This ensures no data loss, matching desktop client behavior.
…es the conflicted copy visible in the app's file list immediately after sync conflict resolution
… in Security settings to choose conflict resolution strategy - When enabled: upload local version (overwrites remote) - When disabled (default): create conflicted copy and download remote - Ensures no data loss while giving users control over conflict behavior
…eSystemWorker now checks for conflicts when forceOverwrite=true - Creates local conflicted copy before uploading when remote changed - Respects 'prefer local on conflict' setting - Works even without Auto-Sync enabled
@zerox80
Copy link
Contributor Author

zerox80 commented Jan 12, 2026

Please test it, and give feedback.
Theres option now with always last write wins (default: Off)

edit: Conflict files are in the OpenCloud Folder, not on Server

@zerox80
Copy link
Contributor Author

zerox80 commented Jan 13, 2026

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants