How to set a folder as available offline?

There’s a menu item for files called Set as available offline. I’m missing this option for folders. I remember that this was available in the ownCloud client.

So how do I set a folder as available offline? Also, does this mean that the folder/file will be updated on the client as soon as there’s a new version on the server?

Also, what does Expert Mode do in settings? (It deoesn’t change any menu items, nor do I see additional settings.)

I’m sorry for these questions but there’s no documentation whatsoever (the only one I could find is which is several years old and outdated).

available offline is not available for folders yet but is planned to be implemented.

Expert mode is activating certain options in the auto upload screen, most prominent feature would be custom folders for auto upload. Other activated things would be the menu within the auto upload screen.

Thank you very much for the reply and the explanation what expert mode does.

2 last questions:

  1. Where’s the documentation? (e.g. to read up on expert mode :wink: , how to setup auto upload, … )
  2. How do I set a file or folder to automatically retrieve the latest version from the server? (When X updates on server, client automtically downloads X.)

Actually there is none, since for the Android client we decided to not update/maintain a documentation

That is only available for files at the moment. In the file browser choose “set available offline” for the file(s) you want to be kept in sync with the server

Sorry to be blunt, but this probably wasn’t the smartest idea. Especially since none of these menu items and settings have any help text in the application.

Thanks for the info. See, this woluld be great to have in the documentation. Even it was just a single file that explains what all these items do.

e.g. what does the menu item Sync do for a folder? It is not available for files. For files there’s only a Download menu item. Are they doing the same? What’s the difference? I think you get the idea…

All good! This has nothin to do with being smart but with limited time and priorities.

Yes I do, absolutely but to be frank I (personally) don’t care for a simple reason: Not everybody can write Android code but nearly everybody is able to write documentation for an existing client.

…yet nobody seems to be up for the task and yes all the devs would probably be happy to answer any question related to the client so somebody would be able to write the docs.
So I myself decided to spend my spare time on contributing code rather than writing documentation because even for contributing code the amount of contributors is rather low (meaning the amount of people who constantly contribute).

1 Like

The idea is rather that you don’t need docs, so the client needs some work so everything is self explanatory.
For example with 3.4 (probably end of 2018) there woun’t be any set available offline / download etc. The client will just always keep any downloaded file in sync with the server and when the people find the time we will also support that for folders an hopefully get to the point of removing the sync menu item too :slight_smile:

Please don’t. Or at least give people a choice between sync / download / set offline / auto upload. There are good reasons why you do not want to automatically update a local file. Please see also how to use those terms correctly at the bottom.

I still don’t know what the difference between the Sync item in the folder menu and the Download item in the file menu is. I guess I have to figure it out by running a few tests.

I think there are a few misused words in the app and how they are used.

Here’s an explanation how these items are understood by non nextcloud developers (I have already found out that for some reason nextcloud devs use terms that are wrong or completely detrimental to the use in the real world):

Sync - two way sync replication
Download - one time download of a file
Set available offline - download a file and keep it in sync with the server - one way sync (server -> client)
Automatic upload folder - one way sync (client -> server)

Don’t get me wrong, I understand how complex such an app is. At one other point I offered to design and work out a dev plan for a feature, but I was just mocked by nextcloud devs and told I could always code it myself. Well, that’s exactly the problem with this project. Everybody thinks they are designers and know how to engineer a piece of SW. False. That’s why terms are used inconsistently and often wrongly in the first place. That’s also how it comes to a misalignment of what a feature is doing and what the rest of the world thinks it would/should do. (e.g. see the endless discussion about group admin functionality - the outcome is that no sane person can use this w/o having to fear the loss of data and productivity)

It is basically the same (from my understanding of the app/code), so sync for folders will simply download its content.

Set available offline is a two way sync at the moment, so it also uploads changes of a file back to the server (!)+

Auto upload as you already stated is kind of a one-way sync while at the moment it is “just” and automated upload for files so it will only upload new/changed files but doesn’t check for deletions and removes files from the server

Can you elaborate a bit on this matter, maybe name an example/scenario? The next release of the Android app will support file versions, so you can see all the versions of a file (created with each change of the file) and restore that version.

See, this is exactly what I mean. Not only the wrong terms, but also inconsistently used.

Also the wrong term. (IMO)

I really would suggest to adhere to the terms I listed above, unless you want to confuse people and make up new terms for Nextcloud once again.
The priority should be to consistently use the correct terms in the app. You can take my list above and put it in the Problem solved. No more wondering what things are doing.

Ouch, this will introduce another problem. The version does not include a comment. So people choose a version on the client. What then? Will the version on the server also be reverted to that version? If yes, how do people get back their lost data?
Seriously, without documenttion this will be a data loss feature instead.

What a versioning feature really would need was a preview capability and the possibility to save a version under a different name.

Or make he terms even more clear:

2-way sync
sync client->server
sync server->client

1 Like

I completely understand the naming issue while the designers (not the developers) aim for having let’s say 2non-technical" terms. We also probably wouldn’t have each type of sync variant like you mentioned in your last post since we have no 2-way sync at this very moment (also 2-way sync is rather tricky or even impossible lookng at Android/Permissions/SD-Card-issues by OEMs) and for the other two one way sync options: We do have a “auto upload” for media folders (images/videos/audio files) which uploads new/changed files to the server but currently doesn’t “sync” a deletion (which might also be a problem, since you cleanup your device but don’t want your camera images deleted on the server of course), sync server->client is also hard to get right, because what should happen when you locally changed the file? Overwrite? Keep changed version?

Again for “download” what would be the benefit/scenario where you wouldn’t want to have the latest version of that file even when you downloaded it some time ago?

As for versioning:

There is no data loss, the client will just “flip the version history” (not sure how to say this correctly since I am not a native speaker). Let’s say you have versions a, b, c with c being the most recent one, when you activate b to be the “active” version the version history will be a, c, b so all versions will always be there and can be accessed, so no data loss (technically speaking).

Saving a file(version) under a different name doesn’t make it a new version (technically speaking) it would just create a new file with a different name, that is not versioning in a technical way. Of course you can always rename files but that has nothing to do with versions. You can then just copy the file, give it another name, do your changes, done. But like I said that is not versioning.

I’ll open up an issue in the dev tracker about the naming discussion, link to be posted afterwards

I created an issue here:

Sorry, for some reason I did not get a mail until today that this topic had been updated. Therefore my late reply.

Yep, this is definitely something that has to be worked out. Maybe an option would help: overwrite, don’t do anything, ask. But in a sync server -> client scenario, overwriting is a valid default.
But this is the reason for the download menu item.

If I didn’t want that the client file to be automatically replaced, I’d choose download. So I have a copy and I can be sure it’s the one I wanted. If I then wanted to replace it, I’d select download again.

Although, if you give users the choice with an option I mentioned earlier, this download will no longer be necessary. But I might be wrong, because the option would most likely be for all files. Download would only affect the selected file/directory.

That’s why I would differentiate between sync server -> client, where the files are automatically updated on the client and download that only downloads a file on request.

Ok, this makes sense. I still would like to see an option for a preview, otherwise you might have a weird history when you are looking for the right file in a set of 10 versions.

I never said it was. I see it as workaround in case there’s no preview.