CLI commands with Web Edition

Can I run CLI commands with the Web Edition?
like opening terminal and typing…

"C:\Users\Carl\AppData\Local\DuplicacyWebEdition\duplicacy_web_win_x64_1.4.1.exe" list

I’m getting some strange web server error?
Can't start the web server at 127.0.0.1:3875...Only one usage of each socket address... is normally permitted

So that led me to kill the DuplicacyWebEdition application, and I ran the command again:
"C:\Users\Carl\AppData\Local\DuplicacyWebEdition\duplicacy_web_win_x64_1.4.1.exe" list
This started the app and opened the web page… but I can’t find any list output…
Help please… :wink:

This is not a cli, this is the web version.

CLI sits under ~/.duplciacy_web/bin. Where is that location on windows… no clue :). If you want to run it for the existing backup defined in the WebGUI you need to run it from a specific folder.

1 Like

~ (referring to home) is basically the same location as on Linux - the user’s home directory/profile.

So C:\Users\<username>\.duplicacy-web.

But if installed as a service and ‘for all users’, it’ll be under C:\ProgramData\.duplicacy-web instead.

I’m apparently still missing something… I’m on my mac now…

Moto-Macbook-Air:bin carl$ pwd
/Users/carl/.duplicacy-web/bin
Moto-Macbook-Air:bin carl$ ls
duplicacy_osx_x64_2.6.2
Moto-Macbook-Air:bin carl$ duplicacy_osx_x64_2.6.2 list
-bash: duplicacy_osx_x64_2.6.2: command not found

What am I missing?

That’s the thing… not specific to this discussion but in general: I wasn’t sure if it was fixed on windows (I.e. my doubt was not about where is home folder located but rather where does Duplicacy stores it’s data, because I hoped it won’t do that in the root of the home folder).

While piling application data and other stuff to ~/.duh on Linux/Unix is somewhat justifiable, it is not on Windows and macOS; both OSes have guidelines about what well behaving app is expected to do.

Windows defines a bunch of locations CSIDL (Shlobj.h) - Win32 apps | Microsoft Docs and guidelines https://docs.microsoft.com/en-us/windows/uwp/app-settings/store-and-retrieve-app-data regarding what data should go where.

Apparently Duplicacy does do the right thing now with ProgramData (it does not dump stuff to c:\Users) but not with user specific app data or configuration data. Why?

This is more egregious on macOS which has explicit dedicated locations for programs, payload, configuration, and cache that are self-documenting by their very names. Littering in the root of users home is not nice. Ok, I can maybe understand putting filters files there. Or maaaybe config json. But caches? They get picked up by time machine, if anything else. I got stuff symlinked to the right places on my Mac — but it’s extra work.

Maybe we shall featurequeat this somewhere. For version 3.0. All it takes is a small adaptation layer that would return “special purpose” folder location for the major OSes.
/rant.

So… that still leaves me with my question…

Sorry about that :slight_smile:

Look in your home folder, c:\Users\C11 there would be a [hidden] subfolder called .duplicacy_web. The CLi binary would be there under bin subfolder.

If you installed Duplicacy for “all users” that would be under C:\ProgramData folder.

What are you trying to accomplish btw, on a high level?

Ah yes, I agree with you there - mentioned something similar a while back.

Though Duplicacy is no means the only program to use the root of the home directory on Windows. I have a lot of ‘dot’ directories from the likes of Atom text editor, and Visual Studio Code no less (Microsoft’s own code editor)!

1 Like

For the GUI version there are some options, but not the CLI version commands.

If you want to use the CLI version with the repositories and storages configured in the GUI version, you must cd to the repository folder you want (C:\Users\<username>\.duplicacy-web\repositories\localhost\xx) and call the CLI version (which is under C:\Users\<username>\.duplicacy-web\bin) from there.

Maybe I’m confused…
With the old GUI application, I could run all the CLI commands from the terminal. My understanding is that the old GUI was just a front end for the CLI. I assumed the new Web-UI was also just a front end to the CLI?
I have uninstalled the GUI and am now running the Web-UI.
But I cannot seem to get the CLI commands to run, see my examples above.
For example: I’d like to run “list”, which is not available in the Web-UI. I also might want to run the others like cat, history, diff, etc.

I never used the old version (I always used CLI before the release of the current web version), so I dont know its functionalities.

That’s correct.

You’re trying to use the GUI executable. Use the CLI executable under C:\Users\<username>\.duplicacy-web\bin.

On Mac, you are missing two characters: ./
To execute a command in the current directory, you need to prefix the file with ./
As in:

cd /Users/carl/.duplicacy-web/bin
./duplicacy_osx_x64_2.6.2 [...]

But more likely, you want to execute that command from the correct (repository) folder:

cd ~/.duplicacy-web/repositories/localhost/xx
~/.duplicacy-web/bin/duplicacy_osx_x64_2.6.2 list

Similarly on Windows:

C:
CD C:\Users\C11\.duplicacy-web\repositories\localhost\xx
C:\Users\C11\.duplicacy-web\bin\duplicacy_win_x64_2.6.2.exe list

OK! Thanks towerbr and Guillaume!
So to summarize, to run CLI commands with the Web-UI:
I want to be in the correct repository “localhost” folder and execute the command directed for the CLI executable that is in the appropriate \.duplicacy-web\bin

OK, so that seemed to work for localhost 0.
YAY!

BUT…
I do use my PC to backup my local NAS to B2, so I have two more local host directories. And I cannot get “list” to work for them…
It doesn’t work for \localhost\1 or \localhost\2
For those, it asks for the application id and key and then for the storage password…but it returns nothing. Actually, it seems to store those keys after the first time, because it hasn’t asked for it again yet. Yes, there are snapshots Could this be a bug? Doing the backup of an outside NAS as localhost 1 and localhost 2 might be unusual…

edit: to be more clear…
THIS WORKS:
C:\Users\Carl\.duplicacy-web\repositories\localhost\0>C:\Users\Carl\.duplicacy-web\bin\duplicacy_win_x64_2.6.2.exe list

THIS DOES NOT WORK:
C:\Users\Carl\.duplicacy-web\repositories\localhost\1>C:\Users\Carl\.duplicacy-web\bin\duplicacy_win_x64_2.6.2.exe list
(It returns no snapshots, but I know they are there.)
EDIT!!!: It looks like this command sets the storage to the wrong place, it selects the storage for localhost 0 instead of localhost 1.

So am I doing the check for localhost 1 incorrectly, or is this a bug?

As preferences files are somewhat repeated in all numbered subfolders of localhost (the content is different, but references all storages) you will have to use the -storage option so that :d: “understands” which storage is desired, something like :

C:\Users\Carl\.duplicacy-web\repositories\localhost\1>C:\Users\Carl\.duplicacy-web\bin\duplicacy_win_x64_2.6.2.exe list -storage <storage name related do backup 1>

WHOOT! That seems to work! Thank you.
I’m confused as to why I had to set the storage for this, as it should “know”. I knows the repository info automagically, why not the storage info? And the commands work find in the Web-UI…

For future readers:
**For mounted network drives the relevant storage must be specified with ** -storage

Take a look at the preferences files in each subfolder.

You will notice that all "names" are listed in all files, but "ids" are repeated in each file.

Therefore, only one key will be correct in each file, and you need to inform the storage ("name") to point to :d: which one is correct.

"name" = storage name
"storage" = storage URL

Ok, so:

In the localhost 0 preferences file:

    "name": "B2forDuplicacy-Garage-Carl",
    "id": "MOTOCAT-Carl-Carl",
    "repository": "C:\\Users\\Carl",
    "storage": "b2://MotoCat-Garage-PC-CARL",

    "name": "B2forDuplicacy-NAS-Vault",
    "id": "MOTOCAT-Carl-Carl",
    "repository": "C:\\Users\\Carl",
    "storage": "b2://SynologyMotoNAS-VAULT",

    "name": "B2forDuplicacy-NAS-Server",
    "id": "MOTOCAT-Carl-Carl",
    "repository": "C:\\Users\\Carl",
    "storage": "b2://SynologyMotoNAS-SERVER",

In the localhost 1 preferences file:

    "name": "B2forDuplicacy-Garage-Carl",
    "id": "MOTOCAT-Carl-V",
    "repository": "V:/",
    "storage": "b2://MotoCat-Garage-PC-CARL",

    "name": "B2forDuplicacy-NAS-Vault",
    "id": "MOTOCAT-Carl-V",
    "repository": "V:/",
    "storage": "b2://SynologyMotoNAS-VAULT",

    "name": "B2forDuplicacy-NAS-Server",
    "id": "MOTOCAT-Carl-V",
    "repository": "V:/",
    "storage": "b2://SynologyMotoNAS-SERVER",

In the localhost 2 preferences file:

    "name": "B2forDuplicacy-Garage-Carl",
    "id": "MOTOCAT-Carl-W",
    "repository": "W:/",
    "storage": "b2://MotoCat-Garage-PC-CARL",
    "encrypted": true,

    "name": "B2forDuplicacy-NAS-Vault",
    "id": "MOTOCAT-Carl-W",
    "repository": "W:/",
    "storage": "b2://SynologyMotoNAS-VAULT",

    "name": "B2forDuplicacy-NAS-Server",
    "id": "MOTOCAT-Carl-W",
    "repository": "W:/",
    "storage": "b2://SynologyMotoNAS-SERVER",

Ah… WHY is it like this?
Why don’t the name, id, repository and storage match in group? It seems ONLY the “id” is setup wrong (or in a way I don’t understand)?
Perhaps there is a good reason…? Or not?

C

Don’t worry too much about the preferences created by the Web Edition. It’s done this way to support backing up the same repository (id) to multiple storages - if later that’s set up. So it’s added all the repositories to all the storages already (because you have multiple storages).

The ‘selector’ is the storage name because it’s not possible to pick one by id here. So when Duplicacy runs each backup, it chooses only the relevant storage names and no other.

Ok, that makes sense. Thank you, I’m always curious about “why”. I can imagine some people would back up their stuff to multiple storages.

It is a bit funky on first observation, because these are “extra” preferences I didn’t specify. I never imagined backing up my repository to multiple locations, and so seeing “preferences” like this was rather confusing.

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.