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

Uploading files create an copy in the /owncloud folder of the device #346

Closed
schiessle opened this issue Jan 13, 2014 · 28 comments
Closed

Comments

@schiessle
Copy link

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.

@davivel
Copy link
Contributor

davivel commented Jan 16, 2014

This is duplicating #156. Please, track it there.

@davivel davivel closed this as completed Jan 16, 2014
@davivel
Copy link
Contributor

davivel commented Jan 16, 2014

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.

@aurusa
Copy link

aurusa commented Mar 28, 2014

is it possible solve this issue with

mStorageManager.removeFile(upload.getFile(), true, true);

inside

com.owncloud.android.files.services/FileUploader.java

private void notifyUploadResult(RemoteOperationResult uploadResult, UploadFileOperation upload) {
   Log_OC.d(TAG, "NotifyUploadResult with resultCode: " + uploadResult.getCode());
   if (uploadResult.isCancelled()) {
      // / cancelled operation -> silent removal of progress notification
      mNotificationManager.cancel(R.string.uploader_upload_in_progress_ticker);

    } else if (uploadResult.isSuccess()) {
       ....
       // Delete uploaded local file 
       mStorageManager.removeFile(upload.getFile(), true, true);
    } else {

???

@davivel
Copy link
Contributor

davivel commented Mar 28, 2014

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:

  • There are two accounts in the device: account1 and accoun2.
  • The user uploads file.txt to account1 ; it's not copied in the ownCloud folder, just linked in the database to its original location
  • The user marks file.txt to be kept-in-sync in account1, so that the file is sychronized automatically when changes appear both in the server or in the app.
  • The user uploads file.txt to account2 (same file); it's not copied in the ownCloud folder, just linked in the database to its original location.
  • The user marks file.txt to be kept-in-sync in account2, so that the file is sychronized automatically when changes appear both in the server or in the app.

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.

@Nowaker
Copy link

Nowaker commented May 8, 2014

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.

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.

Is that what the user is trying to do?

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. ;-)

@enoch85
Copy link
Member

enoch85 commented May 9, 2014

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.

@narddawg314
Copy link

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.

@rickatnight11
Copy link

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. Keep original local files
  2. Server upload only (no local sync)

#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.

@davivel
Copy link
Contributor

davivel commented Aug 6, 2014

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.

@fduraibi
Copy link

fduraibi commented Oct 1, 2014

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.

@jancborchardt
Copy link
Member

How do Dropbox and Google Drive do this by the way?

@rickatnight11
Copy link

I don't know how Dropbox does it, but Google Drive doesn't display local
and remote contents (in sort of a virtual FS like Owncloud does). Drive
just shows you what's in the cloud and allows you to "Save to Device".

  • Rick

On Thu, Oct 23, 2014 at 10:09 AM, Jan-Christoph Borchardt <
notifications@github.com> wrote:

How do Dropbox and Google Drive do this by the way?


Reply to this email directly or view it on GitHub
#346 (comment).

@enoch85
Copy link
Member

enoch85 commented Nov 2, 2014

Drive just shows you what's in the cloud and allows you to "Save to Device".

That would be the best soulution.

@davivel
Copy link
Contributor

davivel commented Nov 4, 2014

@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.

@davivel
Copy link
Contributor

davivel commented Nov 7, 2014

Probably this issue need some love in the near future. cc @rperezb @MTRichards to push higher in priority

@jancborchardt
Copy link
Member

@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.)

@enoch85
Copy link
Member

enoch85 commented Nov 7, 2014

Woohaa!

@MTRichards
Copy link

Roger that.

@tobiasKaminsky
Copy link
Contributor

@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.)

@jancborchardt What do you mean with the part in () ?
I take a photo, it is stored in /sdcard/dcim
I upload it to owncloud (no copy is created)
I open the image in owncloud app and it opens the file in /sdcard/dcim.
Only If the file does not exist there anymore it will be downloaded and stored in owncloud folder, right?

But I see another problem:
I upload a file /sdcard/test.txt
I edit this file on the server/pc/wherever
I update the file in owncloud app:

  • will the file in /sdcard/test.txt be overwritten? (I guess this is thing the user wants)
  • will there be a copy in owncloud folder?

@jancborchardt
Copy link
Member

I open the image in owncloud app and it opens the file in /sdcard/dcim.

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.

@tobiasKaminsky
Copy link
Contributor

No. Not now. My question was if you mean this behaviour?
But yeah, it would be good, if it can work this way.

@jancborchardt
Copy link
Member

Yeah, with (Unless it’s explicitly opened from the app.) I was referring to my impression that we’d have to download the file into the ownCloud folder when it’s tapped. When we can simply open the original file though that’s fine.

@enoch85
Copy link
Member

enoch85 commented Dec 4, 2014

Here is a new suggestion, using checksums.

screenshot_2014-12-05-00-34-54

@tobiasKaminsky
Copy link
Contributor

@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.

@tobiasKaminsky
Copy link
Contributor

Replaced by a clean summarized description of this issue: #819
Please verify that I have summarized this correctly and then it can get implemented this directly.

@drsavoye
Copy link

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.

@tobiasKaminsky
Copy link
Contributor

@drsavoye Please see #819 which will solve this problem once it is implemented.
Also, you do not need to delete the local copy one by one. Simply choose a folder in the owncloud app and delete it completely on the device. This will lead to an existing but empty folder on the device.

@ag14774
Copy link

ag14774 commented May 26, 2022

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

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

No branches or pull requests