Arch Linux User Repository

I'm going to be disowning this package soon. I'm moving away from crashplan and have no interest in maintaining this package, and dealing with usage issues, when I wont be using it.

I'll keep it up to date during the coming months as needed, but if no one else shows up, I plan to disown it at the end of October.

@gadicc, I added some pacman hooks to handle setting/unsetting the immutable flag:

Sets immutable flag after install/upgrade:

[Trigger]
Operation = Upgrade
Operation = Install
Type = Package
Target = crashplan-pro

[Action]
Description = Set immutability of Crashplan Pro upgrade directory
When = PostTransaction
Exec = /usr/bin/bash -c "rm -rf /opt/crashplan/upgrade/*; chattr +i /opt/crashplan/upgrade"`

Unsets immutable flag before upgrade/remove:

[Trigger]
Operation = Upgrade
Operation = Remove
Type = Package
Target = crashplan-pro

[Action]
Description = Undo immutability of Crashplan Pro upgrade directory
When = PreTransaction
Exec = /usr/bin/bash -c "chattr -i /opt/crashplan/upgrade"```

@blackhole, just tested and I'm having the same issue. As a workaround you can restore files using their web interface. I'll see if I can figure out what the issue with the client is.

Is restore working? I see the message "preparing files..." forever I have deleted cache, but same result.

It appears that the new package does not overwrite the jre directory. The new version of crashplan bundles JDK11, but the previous jre is 1.8.0_144 which causes the error reported by billyburly.

Hasn't been working since the update to 7. Getting the following error:

<JAVA_HOME>/lib/ext exists, extensions mechanism no longer supported; Use -classpath instead. .Error creating JVM: -1

If you're using lots0logs' new parameters, which work great, to prevent you from having to download the tgz file and calculate the sha256sum, use 5fd8166f3cf7242f8ede9fe225e9fcea1817068069f6ebbdcce64de373d4a17c.

pkgver=7.0.0 _pkgtimestamp=1525200006700 _pkgbuild=581

Updating a few lines in the PKGBUILD will install the latest version, and I can confirm that it appears to operate properly with Code42/Crashplan servers. Line5: pkgver=6.9.4 Line6: _pkgtimestamp=1525200006694 Line7: _pkgbuild=502 Line20: sha256sums=('4defd4d385b77ab19358d8a811ac4eab17aaf8b5928464121cd8b9e516d07055'

@dark-saber, the flag out of date button is perfect for letting them know. :)

CrashPlanSmb_6.9.4_1525200006694_502_Linux.tgz is out.

From an email I received from CrashPlan:

Important Product Update

The CrashPlan for Small Business Code42 app is intended to back up your user’s business files (pictures, music, documents, etc.), not your operating system or applications. For this reason, we have always recommended you not include applications or large files in your selection as they may not backup correctly. We have allowed you to back those things up, but beginning in May 2019, we are making some additional changes to our file exclusions and will be disallowing the backup of applications, VM image files, and some backup files.

After this change is applied, you will likely see your file selection and backup archive size go down and benefit from faster restores, syncs, and backups. The new excludes are listed below and a full list of excludes can be found here (https://support.code42.com/CrashPlan/6/Troubleshooting/What_is_not_backing_up). Applications: /Users/<username>/Applications, /Applications/, /Program Files/, /Program Files (x86)/ VM image files: .hdd, .hds, .pvm, .pvs, .vdi, .vfd, .vhd, .vmc, .vmdk, .vmem, .vmsd, .vmsn, .vmss, .vmtm, .vmwarevm, .vmx, .vmxf, .vsv, .nvram, .vud, .xva Backup files: .bck, .bkf Other files: .tmp, .part, .rbf, .tib, .sparseimage