Tested 3.0.1 but it crashes

I downloaded the 3.0.1 version.
As it is mentioned here in the forum this should work under osx 10.11 El Capitan.

gchen wrote: “Go 1.17+ doesn’t support macOS version 10.12 or lower, so I decided to go back to Go 1.16 for release 3.0.1.”

I did remove the quarantine xattr and chmoded it with a+x.
But it doesn’t work.

When I call it in the terminal it shows:

dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
Referenced from: /Users/arne/./Downloads/duplicacy_osx_x64_3.0.1
Expected in: /usr/lib/libSystem.B.dylib

dyld: Symbol not found: _clock_gettime
Referenced from: /Users/arne/./Downloads/duplicacy_osx_x64_3.0.1
Expected in: /usr/lib/libSystem.B.dylib

SIGTRAP: trace trap
PC=0x7fff604f7075 m=0 sigcode=1

goroutine 0 [idle]:
runtime.walltime1(0x0, 0x0)
/usr/local/go/src/runtime/sys_darwin.go:289 +0x4a fp=0xc00013f448 sp=0xc00013f410 pc=0x405d84a
runtime.walltime(…)
/usr/local/go/src/runtime/time_nofake.go:23
time.now(0x6f746f72702e656c, 0x580f3a0, 0x0)
/usr/local/go/src/runtime/timestub.go:16 +0x25 fp=0xc00013f478 sp=0xc00013f448 pc=0x4073905
time.Now(0x30, 0x4ec4160, 0x6c676f6f67375a01)
/usr/local/go/src/time/time.go:1067 +0x26 fp=0xc00013f4a0 sp=0xc00013f478 pc=0x40de166
google.golang.org/grpc/internal/grpcrand.init()
/Users/gchen/zincbox/go/pkg/mod/google.golang.org/grpc@v1.28.1/internal/grpcrand/grpcrand.go:30 +0x26 fp=0xc00013f508 sp=0xc00013f4a0 pc=0x459ec66
runtime.doInit(0x5789260)
/usr/local/go/src/runtime/proc.go:6315 +0xec fp=0xc00013f658 sp=0xc00013f508 pc=0x404cdec
runtime.doInit(0x5789220)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013f7a8 sp=0xc00013f658 pc=0x404cd72
runtime.doInit(0x5799ea0)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013f8f8 sp=0xc00013f7a8 pc=0x404cd72
runtime.doInit(0x578cb40)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fa48 sp=0xc00013f8f8 pc=0x404cd72
runtime.doInit(0x57930c0)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fb98 sp=0xc00013fa48 pc=0x404cd72
runtime.doInit(0x5790200)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fce8 sp=0xc00013fb98 pc=0x404cd72
runtime.doInit(0x579e000)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fe38 sp=0xc00013fce8 pc=0x404cd72
runtime.doInit(0x5790c00)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013ff88 sp=0xc00013fe38 pc=0x404cd72
runtime.main()
/usr/local/go/src/runtime/proc.go:208 +0x205 fp=0xc00013ffe0 sp=0xc00013ff88 pc=0x403f065
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc00013ffe8 sp=0xc00013ffe0 pc=0x4076841

goroutine 1 [running, locked to thread]:
runtime.asmcgocall(0x4078040, 0xc00013f428)
/usr/local/go/src/runtime/asm_amd64.s:652 +0x42 fp=0xc00013f3e0 sp=0xc00013f3d8 pc=0x40764a2
runtime.libcCall(0x4078040, 0xc00013f428, 0x30)
/usr/local/go/src/runtime/sys_libc.go:48 +0x6c fp=0xc00013f410 sp=0xc00013f3e0 pc=0x405deec
runtime.walltime1(0x0, 0x0)
/usr/local/go/src/runtime/sys_darwin.go:289 +0x4a fp=0xc00013f448 sp=0xc00013f410 pc=0x405d84a
runtime.walltime(…)
/usr/local/go/src/runtime/time_nofake.go:23
time.now(0x6f746f72702e656c, 0x580f3a0, 0x0)
/usr/local/go/src/runtime/timestub.go:16 +0x25 fp=0xc00013f478 sp=0xc00013f448 pc=0x4073905
time.Now(0x30, 0x4ec4160, 0x6c676f6f67375a01)
/usr/local/go/src/time/time.go:1067 +0x26 fp=0xc00013f4a0 sp=0xc00013f478 pc=0x40de166
google.golang.org/grpc/internal/grpcrand.init()
/Users/gchen/zincbox/go/pkg/mod/google.golang.org/grpc@v1.28.1/internal/grpcrand/grpcrand.go:30 +0x26 fp=0xc00013f508 sp=0xc00013f4a0 pc=0x459ec66
runtime.doInit(0x5789260)
/usr/local/go/src/runtime/proc.go:6315 +0xec fp=0xc00013f658 sp=0xc00013f508 pc=0x404cdec
runtime.doInit(0x5789220)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013f7a8 sp=0xc00013f658 pc=0x404cd72
runtime.doInit(0x5799ea0)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013f8f8 sp=0xc00013f7a8 pc=0x404cd72
runtime.doInit(0x578cb40)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fa48 sp=0xc00013f8f8 pc=0x404cd72
runtime.doInit(0x57930c0)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fb98 sp=0xc00013fa48 pc=0x404cd72
runtime.doInit(0x5790200)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fce8 sp=0xc00013fb98 pc=0x404cd72
runtime.doInit(0x579e000)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013fe38 sp=0xc00013fce8 pc=0x404cd72
runtime.doInit(0x5790c00)
/usr/local/go/src/runtime/proc.go:6292 +0x72 fp=0xc00013ff88 sp=0xc00013fe38 pc=0x404cd72
runtime.main()
/usr/local/go/src/runtime/proc.go:208 +0x205 fp=0xc00013ffe0 sp=0xc00013ff88 pc=0x403f065
runtime.goexit()
/usr/local/go/src/runtime/asm_amd64.s:1371 +0x1 fp=0xc00013ffe8 sp=0xc00013ffe0 pc=0x4076841

rax 0x7fff60530290
rbx 0x5c02160
rcx 0x0
rdx 0x0
rdi 0x7fff60530400
rsi 0x0
rbp 0x7fff5fbff860
rsp 0x7fff5fbff848
r8 0x7fff6051904c
r9 0xffffffff
r10 0x7fff5fbff645
r11 0x7fff60530400
r12 0x1
r13 0x1
r14 0x7fff60530400
r15 0xffffffffffffffff
rip 0x7fff604f7075
rflags 0x246
cs 0x2b
fs 0x0
gs 0x0

Downloaded the former version 2.7.2 again and it does work.
As there are no mentions of this “bug”(?) with 3.0.1 here in the forum I guess there might be something wrong with my OS X 10.11?

Please help.
Thanks
Arne

duplicacy_osx_x64_2.7.2 was built with Go 1.12.9.

duplicacy_osx_x64_3.0.1 was built with Go 1.16.15.

From https://go.dev/doc/go1.16:

Go 1.16 is the last release that will run on macOS 10.12 Sierra. Go 1.17 will require macOS 10.13 High Sierra or later.

Does that mean executables built with Go 1.16 can only run on macOS 10.12 or later? I’m not sure.

The last Go version that supported El Capitan (10.11) was 1.14. Go 1.16 needs Sierra (10.12). Go 1.17 needs High Sierra (10.13).

@arnetietz You will need to upgrade your OS if you want to use the latest versions of :d:

Or build from source yourself

brew install go@1.4
go get github.com/gilbertchen/duplicacy/duplicacy

Maybe some dependencies will need to be rolled back too.

Thanks for your reply.

I run 10.11 El Capitan on a MacMini from 2009, so it is the last OSX Version I can install.
There are patched higher versions of OS X of Sierra and up in the internet but I don’t know if I can trust them and if all my MacMini internals will be working.

There is already go 1.15.8 installed (the highest possible version) on my system from other programs.
I’ll try to build duplicacy 3.0.1 from source.
If it does not work I need to think about updating OS X to a patched higher version.
There is some work to be done for me.

For now I stay with 2.7.2. It works so far.

I would recommend against doing so for a number of reason, especially if this is your main desktop. If, on the other hand, this Mac is being used solely as a network file server (which I myself did in the past with old but perfectly working Macs as well), you may consider installing a lightweight server OS on it instead, for example FreeBSD or Linux, thus avoiding wasting ram on the graphical interface and freeing more resources for actually doing file server related tasks, including running duplicacy.

This shall work. Post and failures and community will try to help figure them out.

Ok, I’ve done it. I compiled it from source.
And it seems to work.

In my home directory:

[~]$ go get github.com/gilbertchen/duplicacy/duplicacy

package io/fs: unrecognized import path "io/fs": import path does not begin with hostname

I just ignored the message and gone further with what it is written in the wiki:

[~]$ cd go/src/github.com/gilbertchen/duplicacy/

[~/go/src/github.com/gilbertchen/duplicacy]$ go install github.com/gilbertchen/duplicacy/duplicacy

go: downloading github.com/gilbertchen/cli v1.2.1-0.20160223210219-1de0a1836ce9
go: downloading github.com/aws/aws-sdk-go v1.30.7
go: downloading golang.org/x/oauth2 v0.0.0-20200107190931-bf48bf16ab8d
go: downloading github.com/gilbertchen/goamz v0.0.0-20170712012135-eada9f4e8cc2
go: downloading github.com/gilbertchen/azure-sdk-for-go v14.1.2-0.20180323033227-8fd4663cab7c+incompatible
go: downloading github.com/minio/highwayhash v1.0.2
go: downloading github.com/vmihailenco/msgpack v4.0.4+incompatible
go: downloading storj.io/uplink v1.9.0
[...]

[~/go/src/github.com/gilbertchen/duplicacy]$ ls -al ~/go/bin/
total 78360
drwxr-xr-x  3 arne  staff       102 10 Dez 19:23 .
drwxr-xr-x  6 arne  staff       204 10 Dez 19:23 ..
-rwxr-xr-x  1 arne  staff  40117336 10 Dez 19:32 duplicacy

[~/go/src/github.com/gilbertchen/duplicacy]$ ~/go/bin/duplicacy 
NAME:
   duplicacy - A new generation cloud backup tool based on lock-free deduplication

USAGE:
   duplicacy [global options] command [command options] [arguments...]
   
VERSION:
   3.0.1 (unofficial)
   
COMMANDS:
   init		Initialize the storage if necessary and the current directory as the repository
 [...]

I copied it as “duplicacy3” into the directory with the old version (under /usr/local/bin/).
Then tested it in a directory that I backed up with duplicacy 2.7.2:

[~/sicherungimac]$ duplicacy3 diff
Storage set to /Volumes/WD2TB/duplicacy/sicherungimac
Parsing filter file /Users/arne/sicherungimac/.duplicacy/filters
Loaded 2 include/exclude pattern(s)
snapshot si at revision 27 is encoded in an old version format

Although there was a message about the unrecognized import path “io/fs” when I got it from github it seems to work nevertheless.
Does it?

The line “snapshot si at revision 27 is encoded in an old version format” is just the message that the repository is from an old version but it is usable with 3.0.1, isn’t it?

And I can switch between using 3.0.1 and 2.7.2 (duplicacy3 and duplicacy)?

I want to test the version 3.0.1 first before I upgrade the repo for “sicherungimac”.

Hm, wait, there was something about it in the forum …
Here, from “gchen”, 6. oct.:

  • CLI 3.0 can read backups created with older CLI versions, so it can replace any existing CLI to work with existing storages without any backward compatibility issue.
  • Backups created with CLI 3.0 won’t be readable by older CLI, which mean if you’ve already created new backups with CLI 3.0, then you can’t switch back to an older CLI version for backup or restore.
  • However, you can still use an old CLI to check or prune backups created with CLI 3.0.

Does it mean that when I do a backup with 3.0.1 “duplicacy3 backup” I cannot use 2.7.2 anymore?

How can I test 3.0.1 (backup, restore, prune,…) in “sicherungimac” without losing going back to 2.7.2?

Yes and no. New files created by 3 will be unusable by 2.

If the target is on server you control – take snapshot, so you can revert.

Else, you can generate a list of files in the target, save it. Then test your 3. And if you want to go back – delete all files that are not in the list you collected above. You will lose backups made with 3, however since duplicacy does not modify files, old files will be intact. Maybe also save config file (even though i don’t think it is changed, but making extra backup of config file will never hurt)