-
Notifications
You must be signed in to change notification settings - Fork 3.1k
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
Uploading files create an copy in the /owncloud folder of the device #346
Comments
This is duplicating #156. Please, track it there. |
Much better, let's do it on the other way. This issue describes the whole situation, since it's not only affecting uploaded images, but all the uploads. So let's keep the ball here. |
is it possible solve this issue with mStorageManager.removeFile(upload.getFile(), true, true); inside com.owncloud.android.files.services/FileUploader.java
??? |
That's not a good point to remove the file. That method is focused in create a notification about the result for the user, and should do only that. The file is explicitly copied into the ownCloud folder after the upload is successful, and the best fix would consist in just not copying it. Besides, that local database should save the original path to the file instead of saving the path in the ownCloud fodler, as it does now. The update is a bit more complex that this suggestion, but not too much. The real problem comes when we need to consider this situation:
In this situation, any local change on file.txt will be uploaded automatically to the ** both servers **. Besides, any change in the server side (or from other client) in account1 will be synchronized to the device, and then to account2. And the same for both servers. And the big question is: should be allow that? Is that what the user is trying to do? If that's not what he is trying, we need to add extra checks to avoid that propagation (now we don't need them, since there are two different local copies of the file). Should we give some way to allow the user to decide if the synchronization from server to server should happen? Still more code needed. |
Absolutely not. "The update is a bit more complex" just because of "saving the original path to the file". Without assuming that, the feature should be very easy I guess. Upload and forget.
The user just wants a file uploaded to owncloud. A user doesn't care about the updates of this file. The user is me in #486. ;-) |
I think that a "direct connection" to your ownCloud would be to prefer. For example, same thing when you want to view a photo on your mobile device - it´s downloaded. Why not just access the photo / file directly from the ownCloud server instead? Even more convenient - no double use of space at all! \o/ Look at ES Filemanager for example: https://play.google.com/store/apps/details?id=com.estrongs.android.pop I actually rather use ES Filemanager to browse files than the owncloud app. It shouldn´t be that way. Try to setup ES Filemanager with WebDAV, and you get exactly what I want. No double copies and no need to delete files afterwards because it´s saved on the device. |
This is definitely a good conversation and a good direction to go. Having internal storage issues constantly since I'm taking so many pictures and videos of my son these days. Also it becomes difficult to remove files locally with the standard android gallery because you can only move 500 files at a time. |
The Owncloud app already seems to do a good job of detecting and indicating server files and files that have been synced locally. When uploading files to Owncloud through the app, these additional options would be awesome:
#1 should be selected by default, and if the user deselects it, the files will be removed from wherever they were after upload completes #2 Should be off by default, which would replicate the current functionality (makes another local copy.) When selected, it will not make a replica in the local Owncloud folder. |
I like this idea of let the user choose about two options, with the 'keep original' as default. Anyway, we still need to deal with the change carefully, and consider the impact of mutiple accounts and auto-sync of favorites. Not telling we do not know how to do it, just that it is not an easy-to-do change. |
I think if a user marked a file to be kept in sync with two accounts then that file is expected to be sync between servers as well. It is like if i have a file that i sync with ownCloud and also another cloud storage solution, so I expect that file to be synced between all servers + phone no matter where the change happened. |
How do Dropbox and Google Drive do this by the way? |
I don't know how Dropbox does it, but Google Drive doesn't display local
On Thu, Oct 23, 2014 at 10:09 AM, Jan-Christoph Borchardt <
|
That would be the best soulution. |
@jancborchardt : Both GDrive and Dropbox keep the file in its original place. They do not duplicate it when uploaded. None of them maps a location in the file system with the contents of their accounts, since both handle a cache where remote files are downloaded when requested. Then, the file is only duplicated if, just after uploaded, it's opened from the app. The cache is handled by the apps mostly automatically, allowing to the user just completely clear it or set the maximum storage used. |
Probably this issue need some love in the near future. cc @rperezb @MTRichards to push higher in priority |
@davivel ok, then we should do it just like them for the time being. That is, not creating a copy in the owncloud folder. (Unless it’s explicitly opened from the app.) |
Woohaa! |
Roger that. |
@jancborchardt What do you mean with the part in () ? But I see another problem:
|
Oh, ok, that works? I assumed we would have to download the image then to the owncloud folder. If we can know / link it to the original image and open that instead it’s even better. |
No. Not now. My question was if you mean this behaviour? |
Yeah, with |
@enoch85 This is the same @davivel is talking the whole time about: storing the original path of the uploaded file in the database. And if the file is opened our app can verify that the file is still up to date. This is done by comparing the modification date of the file on device vs. file on server. |
Replaced by a clean summarized description of this issue: #819 |
Has any progress been made on this? I just purchased the ownCloud app and this bug/feature unfortunately makes it unusable for me -- the app itself functions great, but I simply don't have the storage space to keep two copies of everything I upload, and removing the local copy one-by-one is tedious. I think rickatnight11's idea of letting the user choose how to store the data is great. |
So what was the conclusion? I am using the latest version and I am still getting the same behavior when doing instant upload. Owncloud is duplicating my files on my phone |
If I upload some files from my mobile device to ownCloud than the Android App creates a copy of each files in the /owncloud folder of the mobile device.
This means that if I upload many large files my mobile device can run out of memory. Uploading files to ownCloud should not create a additional local copies of the files. Same is true for images uploaded by the instant upload functionality.
The text was updated successfully, but these errors were encountered: