Make sync mode(default, download-only , upload-only, local-first, no-remote-delete) an option in config

[CaulyKan]

When using docker with onedrive, it's quite a difficult work to modify entrypoint.sh and change arguments of onedrive command. So it would be better to make use of config file to take full control of onedrive behavior, especially the sync mode.

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Add a sync_mode option to config file, available values:

• default
• upload-only
• download-only
• local-first
• no-remote-delete
  and use them the same way they work in arguments.

[norbusan]

Hi

I think in principle it is a good idea what you propose, only that the format is not optimal. How would you specify an upload-only with no-remote-delete?

So if we go in this direction, I suggest that every command line option can have a respective setting in the config file, and the command line takes priority over the config file (as usual).

@abraunegg WDYT? Should I look into this?

[abraunegg]

@CaulyKan
It is certainly an interesting use case, however I need to understand further how any why 'modify entrypoint.sh and change arguments' is so difficult in a docker environment.

@norbusan
Agree - the proposed method is sub-optimal.

Potentially what would be better is:

cli_options = "<your desired options> eg: --single-directory 'blah' --upload-only"

This then could accept any number of valid parameters, with then any actual CLI entries taking further priority.

So if we go in this direction, I suggest that every command line option can have a respective setting in the config file, and the command line takes priority over the config file (as usual).

We could also go in this direction where the command line option makes sense for a 'config' file option. Switches like --source-directory & --destination-directory for moving folders on OneDrive would not make much sense to have a 'config' file option.

[norbusan]

@abraunegg agreed that some switches don't make sense, indeed.

Concerning the cli_options versus single options, I am undecided. Parsing the cli_options with spaces, embedded " etc might be a bit a pain. Also I think that having single options is a bit clearer.

So I would tend to have single options instead of one cli_options, but it is really a matter of taste and I don't have strong feelings about it.

If we agree on one method, I can look at the implemetation

[CaulyKan]

As far as I can tell, there are several ways to modify entrypoint.sh:

1. clone the repo and edit entrypoint.sh, then docker build.
2. make a new dockerfile like 'FROM origin CP new_entrypoint.sh ENTRYPOINT new_entrypoint.sh' and build it.
3. run the image and then exec -it bash into it and vi entrypoint.sh. However I'm not sure why this method can't be used becaused every time I try to do this with onedrive container I got an EOF only.

The third way have other problem: when the container starts the sync starts immediately. If I want to change to upload-only I have to disable the config to make the sync fail.

[norbusan]

I agree with @CaulyKan that adjustment of the docker entry points is not what we want to be necessary. In an ideal world it should be as described in the docker/README.md and configuration option can simply be set in via -v onedrive_conf:/onedrive/conf which makes maintenance much easier.

[CaulyKan]

I've submitted a pr on docker/README.md #358

[CaulyKan]

By the way, is there any one working on gui? I think a self-contained web ui should work best with docker. If nobody is working on it, maybe I can give a try.

[norbusan]

@CaulyKan gui discussion is not really related here, but no, nobody works on it AFAIS. I have looked into writing a applet in D, but GUI toolkits for D are rare and a bit a pain. Furthermore, the current onedrive client is not set up in a way that it could communicate with a frontend (no multi-threading, information handling ...).

So writing a GUI - even a self-contained web ui which needs support from the backend - is future work which we haven't initiated by now.

[abraunegg]

@abraunegg agreed that some switches don't make sense, indeed.

Concerning the cli_options versus single options, I am undecided. Parsing the cli_options with spaces, embedded " etc might be a bit a pain. Also I think that having single options is a bit clearer.

So I would tend to have single options instead of one cli_options, but it is really a matter of taste and I don't have strong feelings about it.

If we agree on one method, I can look at the implemetation

If it is simpler & easier for each option to have it's own 'config' option, then no issue there.

[norbusan]

Merge into master, I think this can be closed.

[abraunegg]

PR #389 merged

[abraunegg]

Re-opening issue as PR #389 broke client configuration option parsing

[CaulyKan]

eh...document not updated? not sure how to start with the new version, where shall I put sync mode in config?

[abraunegg]

@CaulyKan
Can you please help test and evaluate PR #449 against this feature request to have all CLI options as a config file option?

git clone https://github.com/abraunegg/onedrive.git
cd onedrive
git fetch origin pull/449/head:pr449
git checkout pr449
make
make install

Any feedback you have is greatly appreciated

[abraunegg]

Closing as PR #449 merged

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.