Andrea Mazzoleni

The newly released version 14.8 will now detect this condition when saving the content file, preventing it from becoming impossible to load. It makes sense to upgrade to this version.

Minor bugfix release that addresses user-reported issues. If all goes well, this will be our last stable release before we dive into a new beta cycle for SnapRAID CLI 15.x and SnapRAID Daemon 2.x! If you're curious about what's coming next, feel free to check out the HISTORY files in the GitHub repositories. CHANGES IN SNAPRAID 14.8 ======================== * Avoid spinning up standby disks on Windows in some machines during the 'probe' and other device-monitoring commands. Direct system queries...

Did you have a rehash in progress? (Meaning that you had started a snapraid rehash) I'll investigate further to find the possible cause. In general, such internal inconsistencies are caused by memory malfunctions that result in corrupted data being written to the content file. It might be worth running a memtest as well. Regardless, I don't think it's recoverable. It would be better to start from scratch by deleting the content file and running a new sync.

Yes. The idea is that the new hash function will never use a salted hash, so while performing the required progressive (and transparent) rehash during scrub, you'll get the new hash and eliminate the salt at the same time.

There is essentially no downside. It's just a privacy feature that prevents checking a stolen content file for known hashes to identify files. However, considering that the content file also contains the filenames, it is of dubious utility. I'm considering removing it when I enable the new, faster MuseAir hash.

The content files are all saved as temporary files first. Only if all of them are saved successfully are they renamed to their proper names, overwriting the old copies. If even a single file fails to save, none of the others are updated either. If you have autosave enabled, the latest successfully saved intermediate state remains valid.

The problem is that SnapRAID uses salted checksums, meaning that identical files in two different arrays will have different checksums.

Minor bugfix release that addresses user-reported issues and fixes a regression regarding saving config files introduced in SnapRAID-Daemon 1.10. CHANGES IN SNAPRAID 14.7 ======================== * Fix the 'touch' command on Windows for files with the read-only attribute. The read-only attribute is temporarily removed and then restored. No need to update if you are not on Windows. CHANGES IN SNAPRAID DAEMON 1.12 =============================== * Fix configuration saving under SystemD due to read-only...