CLI Features implemented in GUI

Feature
#1

Not all platforms react in the same way to CLI commands.

While e.g. in Windows, among other things, the CLI parameter -reset-deltas reacts as expected, the process reacts only to a limited extent in other environments. If this e.g. run on a Synology in this way as

/var/packages/syncthing.net/target/bin/syncthing -reset-deltas

Although the process starts, it does not work as required, even if the syncthing process is stopped. Such differences also lead to uncertainty when the processes show up differently.

The feature request would be that all CLI functions are integrated into the GUI so that their correct and efficiently usable functionality is given. This would also simplify the support.

1 Like
How to build a Syncthing MSI package for distribution #syncthing-msi
#2

Sounds like a good idea. Maybe Syncthing’s monitor process can do the --reset-deltas by exit code? Or let’s just have an exit code where wrappers can do the --reset-deltas restart accordingly if they see it.

I have to do the same extra work every time a delta reset is required on my QNAP devices. This is SCPing in, going to a deep QPKG subdir and editing the wrapper shell script plus later returning to change it back to the original version.

#3

How so?

#4

Probably because it runs with a different user and home directory when run by the actual start script, so what he does on the command line as another user has no effect.

1 Like
#5

Is difficult for me to see the effect of that circumstances. During my activities on Synology the command line user is root and not syncthing.net

#6

For a -reset-deltas I stop the service and start with syncthing -reset-deltas. On Windows e.g. with

C:\Program Files\Syncthing\syncthing.exe -reset-deltas

I can then observe that the GUI reactivates and the processes work differently than in normal operation. The CMD also cooperates in a traceable manner in parallel.

If I do the same with a Synology, there is no interaction. There are also no noticeable changes, as is the case with Windows when there is an error.

#7

Well, if there’s a start-up script running Syncthing as a special user, you’ll need to run as that user, too. At least it sounds like it isn’t doing user namespacing…

#8

On Synology I can Syncthing manually start, stop, restart with the synoservicecfg command. E,g, start with

synoservicecfg --start pkgctl-syncthing.net

If I try to start --reset-deltas in that way

synoservicecfg --start pkgctl-syncthing.net --reset-deltas

it doesnt run. What is wrong?

#9

You can’t pass application arguments to package manager command, the two are unrelated, and that will never work.

#10

The question is what is the solution for such cases.

If I don’t start Syncthing via the package service, and want to start the binary directly

/volume1/@appstore/syncthing.net/bin/syncthing --reset-deltas

the productive database is not addressed, but a new one is created under

/volume1/@appstore/syncthing.net/.config/syncthing/index-v0.14.0.db/

However, the existing one is located under

/volume1/syncthing-data/index-v0.14.0.db/

which of course is not addressed.

#11

Then you need to specify the --home option in addition.

How to build a Syncthing MSI package for distribution #syncthing-msi
#12

That works … :sunglasses: