-
-
Notifications
You must be signed in to change notification settings - Fork 871
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
Bug: Resync required everytime when using skip_file on CLI #3056
Comments
This is not a bug. You are "changing* the defaults when using --skip-file via the CLI. Please read: |
Thanks for your reply. Maybe the description was not clear enough. I understand resync is required once when changing from the default to a custom skip_file setting. But a resync is required everytime the application starts, even when the custom skip_file setting does not change. This behaviour was different pre v2.5. When changing skip_file in the config file I need to do a resync only once and after that it is not required anymore. I would expect the same behaviour when setting skip_file through the CLI? |
Corrrct because the application configuration has been set, updated and this is what is used.
No because you are overriding the configuration. The application order of options are: Application Defaults -> config file -> CLI options When you change things with the CLI use that require a resync, this is then required
The non requirement of resync when using CLI skip file option was a bug in v2.4.x that you were exploiting. This bug has been fixed in v2.5.x |
Okay. Thanks. So to set a skip_file filter without requiring a resync each time the application starts, requires this doing this through the config file. Using the skip_file option on the CLI always requires a resync if it's different from the application default*. Even if you use the same pattern everytime you start the application? *since I have not configured it in the config file atm. |
The application makes checks to ensure there is valid change before making a resync requirement. |
I don't that is happening in my case. I tried to describe it in Steps to reproduce the behaviour
|
You are changing the application defaults by use of --skip-file The defaults are being changed. This is why resync is being required. In your scenario when you first initiate the resync - because you changed the application defaults. The second is the exact same situation you are changing the application defaults. When you configure the skip_file option in the configuration file - this becomes the new defaults thus on subsequent use does not trigger the --resync requirement. |
Describe the bug
Observed behaviour: When setting the skip_file config option through the CLI, onedrive sees this as a CLI override of the config file even if the CLI provided option is the same. The application exits and requires starting it with the resync option.
The config file seems to be created automatically by the application and contains only the default sync_dir.
Expected behaviour: When the same CLI provided skip_file options is used, a resync is not required.
I run onedrive using the docker image and prefer setting the config option through environment variables / CLI instead of modifying the config file. This used to work in versions prior to 2.5.
Operating System Details
== Host OS == Linux nuc 5.15.0-127-generic #137-Ubuntu SMP Fri Nov 8 15:21:01 UTC 2024 x86_64 x86_64 x86_64 GNU/Linux No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.4 LTS Release: 22.04 Codename: jammy
Client Installation Method
From Distribution Package
OneDrive Account Type
Personal
What is your OneDrive Application Version
onedrive v2.5.3-27-g71a71da
What is your OneDrive Application Configuration
What is your 'curl' version
Where is your 'sync_dir' located
Local
What are all your system 'mount points'
What are all your local file system partition types
How do you use 'onedrive'
OneDrive account/folder is used on multiple systems.
The onedrive application syncs this for backup purposes once every hour (download only with cleanup). The application syncs only one account.
Steps to reproduce the behaviour
Complete Verbose Log Output
Screenshots
No response
Other Log Information or Details
No response
Additional context
I used the latest edge version of the container from december 16th 2024. In my setup the entrypoint.sh does have some minor modifications to support additional CLI options through environment variables and check whether the mount point with the data is correctly mounted.
skip file option used:
*|.|.tmp|.swp|.partial|*.mp4The text was updated successfully, but these errors were encountered: