You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Track auto upload files when original file is "kept in original folder" #12967
Is your feature request related to a problem? Please describe.
The On Device feature is currently the only way for me to (relatively) quickly clear local files to save space on my device. However, auto upload files using the kept in original folder option do not track the original source file in a way that is compatible with the On Device feature. In order to remove these files, I must manually delete them after checking to see if NextCloud uploaded them.
Describe the solution you'd like
I would greatly appreciate if files synchronized via auto upload would be mapped to the original file in a way that allows the file to show up in the On Device feature. This way, I can choose when to delete files that have been uploaded regardless of their current location. Once the file no longer exists on the device (whether from cleanup or deletion by another app), the mapping can be discarded and future downloads can use the NextCloud data folder.
Describe alternatives you've considered
I have considered using the deleted option for original files, but that risks an error resulting in lost files which defeats the purpose of NextCloud as a backup. I prefer to manually review the upload errors to resolve problems and then clear the space myself.
I have attempted to use the moved to app folder option, but it complicates the use of other apps when interacting with the original files. For example, I might use an app similar to Google Photos as my primary way to interact with on-device media, while using NextCloud to backup to a private cloud. That app may expect to find media in the typical system folders and - while it might be able to access media in other folders - the user experience is significantly diminished.
Additional context
N/A
Reacted by enoch85, Álvaro Tejero-Cantero, Tamás Nagy and phildong
From a technical standpoint, it would be useful to have that information on the database (knowing that a certain local file corresponds to a certain uploaded file, even if the file is ouside of the application's own folders).
The problem is, it can't be mapped using the same db column we already use for the manually uploaded files ("media_path"), because it's technically wrong (I tried, as a proof of concept, in this discarded PR: #17522 ).
The right way would probably be adding another column "for future proofing" (this is worthless until it's filled with data). This would benefit cases like the functionality that frees up space deleting already autouploaded files: #17516
This wouldn't necessarily display the green tick mark on the file like the manually uploaded/downloaded files, that should be discussed.
Activity
enoch85 commentedon May 31, 2024
My solution to the problem is:
I agree that this would be a great feature!
daniele-verducci commentedon Aug 26, 2026
From a technical standpoint, it would be useful to have that information on the database (knowing that a certain local file corresponds to a certain uploaded file, even if the file is ouside of the application's own folders).
The problem is, it can't be mapped using the same db column we already use for the manually uploaded files ("media_path"), because it's technically wrong (I tried, as a proof of concept, in this discarded PR: #17522 ).
The right way would probably be adding another column "for future proofing" (this is worthless until it's filled with data). This would benefit cases like the functionality that frees up space deleting already autouploaded files: #17516
This wouldn't necessarily display the green tick mark on the file like the manually uploaded/downloaded files, that should be discussed.