Data loss when a disk changes! Very dangerous flaw!

Hi!

I'm testing SnapRaid and I do like the concept. However, it seems to have a MAJOR flaw causing potential data loss! My scenario is as follows: I have several hard drives with media files and I want to secure groups of 3 with 1 parity drive. Under Windows 11, I use this config file:

content E:\snapraid.content
content F:\snapraid.content
content G:\snapraid.content
data d1 E:\
data d2 F:\
data d3 G:\
parity H:\snapraid.parity

The disks are connected via USB3, hot-swapable. So far, so good. I can sync the disks and the parity will be created ok. I can then remove all disks, attach another set of 4 drives and repeat the procedure. Again, works fine.

When the drives are mounted in different sequence, so that the drive letters change, SnapRaid reports that at least 2 UUIDs have changed and stops whatever it should do (e.g. a sync) - this is correct and fine! i can put the disks in correct order (drive letters) and run the sync fine.

Now for the problems: when I accidentally use a wrong parity disk (one of another set), sync reports that one UUID has changed, but still continues to process the set, thus destroying the parity file on the parity disk! This means the other set (the parity disk actually belongs to) is now UNPROTECTED without me noticing it! The same seems to occur if I exchange a data disk - if it's only 1 UUID that has changed, sync continues to process and destroys parity data!

This is horrible an must not happen in any case!!! ALL UUIDs must be checked and must be correct before ANY destructive operation is started. SnapRaid should immediately terminate if ANYTHING seems suspicious (a changed UUID is always a serious problem!)

Am I doing anything wrong or how can I make sure the sync operation does not run if I accidentally use a disk of a different set?

It would even be better if SnapRaid would use the UUIDs only and ignore drive letters! This way, it would immediately see that a disk is missing and abort any operation (except restoring a failed disk, of course).

Regards!

MAJOR / Dangerous flaw ??

The flaw is you.
For the scenario(s) you're describing, you should be using Windows MountPoints.

Also, remember. you were Warned, but did not heed the warning.

====
"When you make something Idiot-Proof, only idiots will want to use it."

Why MountPoints? Seems to be (mount)pointless... Try understanding my post: I have several sets of 3 data disks, that are connected to the PC maybe once a week for backup purposes (hot-plug). No matter which set I use, they will always be drives E., F. G: and H: )for parity). This way, I do not need to change the conf file, all set-dependent data is stored in the contents files on the respective discs. This is easy and elegant. However, the serious FLAW of SnapRaid makes it dangerous, because it does not seem to stop destructive processes when any one UIID has changed. This would be easy to fix, I guess... Look at Windows Storage Spaces for example: if you attach a disk that is not part of the space, Windows immediately recognizes this and does not destroy any data. Same should be true for SnapRaid: if a drive is not part of the set, SnapRaid should give a warning and stop processing any disks.

And I don't get what you mean by "you were warned", and I don't know what "heed the warning" means...

1) RTFM.
2) Don't use USB. If you have to use USB use mount-points so then Windows handles the unique identifiers.
3) Use Linux instead with UUID mounting.
4) RTFM
5) Use something else.

Snapraid will not hold your hand in this situation because it's not responsible for the underlying filesystem, only the files that are on it. The filesystem is your responsibility.

I used to use Windows with Snapraid + DriveBender, eventually got sick and tired of Windows' limitations and DriveBender's incompetent developers and new owner. Switched to Linux and Mergerfs on eSATA/SAS drives 4 years ago and haven't been happier. USB + Windows is just asking for problems imo.