Windows 11 CLI init Command does not pay attention to current working directory

I have set up the following on my Windows 11 PC:


D_MyProject // SYMLINK to D:\Documents\Product\MyProject
.duplicacy // Directory created with original “duplicacy init” command

C:\Program Files\Duplicacy\

duplicacy.lnk // shortcut to C:\BackupRoot\duplicacy_win_x64_3.2.3.exe
// Allows duplicacy CLI to be executed from PATH with a simple “duplicacy” command.


// This is the project tree I want to backup.


// This is where the backup contents will be stored.

My observations:
Regardless of where I change directory to, the “duplicacy init” command always wants to create the .duplicacy directory where duplicacy_win_x64_3.2.3.exe resides (in C:\BackupRoot.)

So when I want to restore my backup to, for example, D:\BackupRestore, I do the following:

C:> D:
D:> cd \BackupRestore
D:> duplicacy init MyProjectBackup S:\MyBackupStorage

I then get the warning:
The repository C:\BackupRoot has already been initialized

If I go ahead and do the restore:

D:> duplicacy restore -r 1

Nothing happens in the D:\BackupRestore directory:
Storage set to S:\MyBackupStorage
Loaded 0 include/exclude pattern(s)
Indexing C:\BackupRoot
Parsing filter file \?\C:\BackupRoot.duplicacy\filters
Loaded 0 include/exclude pattern(s)
Restoring C:\BackupRoot to revision 1
Restored C:\BackupRoot to revision 1
Total running time: 00:00:01

… which is not what I want at all. What am I not understanding about this?

In the Duplicacy quick-start CLI guide, I see statements like “Duplicacy is very flexible in this regard, as it allows you to create a new repository no matter where it is,” but I’m not finding this to be the case because regardless of where my current working directory is, duplicacy always wants to perform inits in the original C:\BackupRoot directory.

Any suggestions?

This is correct. Duplicacy always initializes the current working directory as the repository (which means the source directory to be backed up in our terminology). The -repository option is designed so that you can specify another directory as the repository while setting up the .duplicacy subdirectory under the current working directory.


I don’t want to be disagreeable, but what you’re describing about the current working directory is not the behavior I’m seeing from duplicacy CLI.

I’m defining “current working directory” as the directory I “cd” into from the windows CMD prompt.

When I do the following:

C:> D:
D:> cd \BackupRestore

I consider the current working directory to be D:\Backup\Restore at this point in time.

When I then run (with the -repository option) :

D:> duplicacy init -repository D:\Backup\Restore MyProjectBackup S:\MyBackupStorage

duplicacy responds with:
“The repository C:\BackupRoot has already been initialized.”

… and my current working directory (D:\Backup\Restore) is empty.

duplicacy “init” is not creating the .duplicacy directory in the current working directory D:\Backup\Restore, and the “repository” item in C:\BackupRoot.duplicacy\preferences shows:

“repository”: “”,

duplicity “init” seems to always use C:\BackupRoot.duplicacy no matter what my current working directory is and no matter whether I use the -repository option or not.

Any suggestions?

BTW… here is “duplicacy -help” so you can see the version of duplicacy I’m using:

D:\BackupRestore> duplicacy -help
duplicacy - A new generation cloud backup tool based on lock-free deduplication

duplicacy [global options] command [command options] [arguments…]

3.2.3 (254953)

Is ‘duplicacy’ a script or the renamed duplicacy_win_x64_3.2.3.exe executable?

As stated in the OP…

I did it this way because if I put duplicacy_win_x64_3.2.3.exe directly into C:\Program Files\Duplicacy\ “init” tried to put the .duplicacy directory there. It seems wherever the actual duplicacy_win_x64_3.2.3.exe exists, that’s where “init” wants to put the .duplicacy directory.

I didn’t want “init” stuff in the C:\Program Files\ area.

BTW… there is a typo in my 7 Mar 2024 10:13 post… I meant to type

with a backslash between the path elements, like this: “BackupRoot” \ “.duplicacy”

Sorry for any confusion.

Doesn’t windows .lnk file already contain current directory for the executable?

Instead of the lnk file you probably want to add path to folder containing duplicacy to PATH and create an alias (in a windows signature roundabout way) if you don’t want to address it by full name.

Thank you @saspus. You were exactly correct, and now that I think about it, it makes perfect sense about the lnk “Start In:” field.

I ended putting both the actual duplicacy executable and a .bat file which calls the executable in C:\Program Files\Duplicacy. This works very well, and it will avoid some of the limitations of Windows aliases. Your suggestion put me on the right path.

1 Like

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