Hello everyone, this is my first post. I’ve been hoping to create my own lbb for over a year or so… after a recent family gathering where I was running a video camera and two go-pros, I finally decided it was time to build one. I ordered the recommended display from amazon as I thought it was a cool factor for the device. I spent some time last night and got everything up and running… To my surprise my intended use of LBB wasn’t available…
I understand the risks, however my plan for LBB was to dump sd cards on the fly. I often end up pulling out my laptop, connecting a reader… transferring / clearing off the sd cards to an external, then continuing on filming etc. It’s quite a mess to have a dedicated space with a macbook, usb cables, charger etc all laid out in a spare bedroom of a family gathering.
Would it be possible to add a feature to copy, verify successful copy, then delete source to free up space / the cards? I actually planned to do this and have 2 target ssd’s… dump sd cards to the first ssd and then copy the ssd to the secondary ssd using lbb.
also a side question / thought… i always create checksum hashes of my files… i didn’t know if there would be a way to automate checksum hashes of files after they have been copies… i have no idea how long this would take on a pi 4 as i know it is cpu intensive.
Either way thank you for the great project… I’m sure i’ll use it regardless if the features I’m requesting can be implemented.
I’m a horrible coder but I can read enough of it… trying to do it myself for the time being. i managed to add a new button to the main gui for this. gonna add the flag to rsync to delete original files to a custom line in the backup.sh
i was trying to edit the backup.sh and the index.php to allow for a new variable for move but i think im just gonna try cloning the backup.sh and changing the rsync to include the delete original flag and then on index.php have the button call move.sh (changed backup.sh) instead of the original backup.sh. we’ll see if that works enough. (probably not the best way to do this)
Dangerous stuff, but it should be possible. I would first back up the image files and then at least compare the file sizes, better a hash sum. And only after that delete the source file.
I don’t have the device, but you can post the code of that file here.
I agree with your logic about backing up first and comparing files before deletion. I believe this is built into rsync already.
-c, --checksum
This changes the way rsync checks if the files have been changed and are in need of a transfer.
Without this option, rsync uses a “quick check” that (by default) checks if each file’s size
and time of last modification match between the sender and receiver. This option changes this
to compare a 128-bit checksum for each file that has a matching size. Generating the checksums
means that both sides will expend a lot of disk I/O reading all the data in the files in the transfer
(and this is prior to any reading that will be done to transfer changed files), so this can slow
things down significantly.
The sending side generates its checksums while it is doing the file-system scan that builds the
list of the available files. The receiver generates its checksums when it is scanning for changed
files, and will checksum any file that has the same size as the corresponding sender's file:
files with either a changed size or a changed checksum are selected for transfer.
Note that rsync always verifies that each transferred file was correctly reconstructed on the
receiving side by checking a whole-file checksum that is generated as the file is transferred,
but that automatic after-the-transfer verification has nothing to do with this option's
before-the-transfer "Does this file need to be updated?" check.
if i were a better coder or if the author of this project sees fit to add this functionality himself… perhaps there is a more secure method than relying on rsync to verify successful transfer.
as of now i have successfully added a new button to the web gui that kicks off a move.sh which is a clone of backup.sh and adds the flag to remove the original files. I did a test run and this actually works. i might add the checksum flag as well to see if it generates the hashes i am looking for… not sure if it actually saves them as an .md5
my last step would be to get this working as the default backup behavior.
I think, the risk of unsuccessful transfer by rsync despite checksum verification is rather small. The risk for the data lies in the fact that it is stored as a single copy and a storage device or file system can always suddenly fail. So, if you can live with the fact that you have only one copy of an image (on SD card or LBB), relying on rsync transfer should not be a problem.
If you want more security, keep the copy on the SD card or use a camera with two cards.