Integrate with time machine snapshots/use APFS snapshots
Low priority: Finding out how APFS sparse files work and supporting those
Current test version:
Known issues:
The folder /Library/Application Support/UrBackup Client/var/urbackup/data isn’t created during installation. This causes file backups/settings exchange to fail.
That’s pretty much right, yes. At present I’m working on (as far as I can see) the last show-stopping issue otherwise, which is to integrate the wxWidgets libraries into the application bundle, so they don’t need to be installed separately.
I have Apple developer membership through the company I work for - but I’m unclear on the best practice for signing apps on a shared, open-source project. Obviously I don’t want to risk my company’s certificate being revoked for sections of code I have no control over - but contrarily, I understand you might not want to sign code that you haven’t written!
I honestly don’t know if I’m being paranoid here - but I just don’t want to jump into a situation which might be irreversible, without fully understanding the consequences…
I don’t yet know how possible this will be: full integration appears to be reserved for select developers - and Time Machine snapshots will get cleared up by the OS after ~24 hours. This might be sufficient to effect a practical solution - at least individual files won’t be transient whilst they’re being backed up, but it won’t necessarily be possible to backup a full disk snapshot within that time period.
Other items I have on my non-show-stopper list are:
I’m not convinced that background priority is being correctly applied;
Work through macOS-specific metadata backups - as per this thread;
I’d link it statically (*.a files). Since there is only one executable file, you wouldn’t gain anything by dynamic linking anyway.
I’d use a separate one. I was asking because I can forward you the fees from donations, if necessary, or perhaps others could help.
I currently don’t have one. As perhaps mentioned in the other thread, the Mac stopped getting updates. Then Apple required an (up-to-date) i-Device as second factor for the developer account. At this point I couldn’t even cancel the account anymore and support wouldn’t cancel the account for me. Luckily my credit card CVC changed which fixed the issue.
I would perhaps consider building it on https://www.macincloud.com/ but if that i-Device second factor requirement still exists, I’d have to buy an Apple device anyway, so it’s cheaper if you do it
No problem - presumably that would be best tied to an @urbackup.org email address? I’m happy to work however’s best for you on this front - just let me know what’s best for the project, and what’s easiest for you.
I can’t exactly remember the sequence of events - but I remember this happening and being annoyed by the prospect. However, someone then just pointed out to create a second user account on my Mac, sign that account into the iCloud account, and use that for the two-factor sign-in - no i-Device required.
Certainly for the foreseeable future, I’m happy to do the build process. I haven’t yet gone through a build which ties into the get-the-version-number-from-git procedure - but I’m happy to work it out (presumably this requires coming out of the dev branch?).
It doesn’t properly switch into dark mode ( https://trac.wxwidgets.org/ticket/18146 ). This seems to be improved with wxWidgets 3.1.y. Any reason why you emphasize using the stable wxWidgets version in the readme?
Woop - I apologise on behalf of the Apple community, and thankyou for your persistence!
Hmmm - it does work here - I can’t think why that wouldn’t get created, just as it was previously created inside the application bundle with the old version.
Yes - it didn’t build for me at all with the later wxWidgets. Since I found 3.0.5 stable worked, I haven’t tried again - I’ll put it on my list and report back. (Sorry - haven’t had much time to spend on this recently.)
(Incidentally there’s an outstanding PR for linking the required wxWidgets into the application, so no separate installation of it is required. )
Sorry, didn’t see. The above build is statically linked (which would in this case also e.g. reduce the size). I updated the readme w.r.t. that.
Could be it was another issue… I had problems with / in the mac serial id (which is added to the default client name), but that problem was fixed server side.
Finally had chance to run your build on a macOS 10.15 system.
I found that with your built package - but it looks fine on my (earlier) build script. Presumably something amiss with line 165 of Makefile.am_client ?..
Again, with your built package on my macOS 10.15 system, that is working here.
One cause could be that depending on the amount of data it needs to send to the server (depending on amount of users e.g.), it uses different methods to call the web browser:
I’m trying to set up an urbackup client on MACOS 10.14 and 10.15.
I can’t do it.
If I download the client from the web interface, it doesn’t work and if I download the versions of this post, I can’t configure it.
After that, you should be able to run and configure the client successfully. You will also have to give the client Full Disk Access in System Preferences > Security & Privacy > Privacy > Full Disk Access.
The installation of version 2.5.7beta is error free.
I executed these three command lines
"
sudo mkdir /Library/Application\ Support/UrBackup\ Client/var/urbackup/data
sudo chown root: /Library/Application\ Support/UrBackup\ Client/var/urbackup/data
sudo chmod 700 /Library/Application\ Support/UrBackup\ Client/var/urbackup/data
"
I changed the second one from root:root to root: OK
I gave access to the entire hard drive to Urbackup client. OK
I can’t set up the client. I have only 4 choices from the URBACKUP client icon.
Access Backups, about, status, uninstall.
sudo urbackupclientctl status
Password:
/usr/local/bin/urbackupclientctl: /usr/local/bin/urbackupclientctl: cannot execute binary file