Yay! We're making progress! Here are the files.
Indeed we are. So much so in fact that it appears that the problem has been solved!
The script has determined the following partitions for the backup task:
Code:
sourceEFIPartition = disk1s1
destinationEFIPartition = disk0s1
Referencing these in your
diskutil list output gives us the following disks:
Code:
"disk1s1" -> belongs to "disk1" -> is container for "disk4" -> is APFS volume "Catalina"
"disk0s1" -> belongs to "disk0" -> is container for "disk3" -> is APFS volume "Catalina Clone"
As such we can now see that the two partitions were correctly found!
I'd like
@CaseySJ to take a look at the results as well, just to double-check everything, but I believe this issue has thus been fixed for good.
The EFIClone-v3-experimental script is exactly the same as the current one with the fix applied, so it should be good to drop-in and replace the current one after validation.
The issue lay in the
getEFIVolume method. It receives as input the disk we want to find the EFI partition for, i.e. "disk4". The problem was that it was checking for string equality in a somewhat open-ended fashion using
grep "$1". Given the string "disk1" as input, it would match all disks that contained this string.
This is where we find out why this issue only affected very few people, those with a large amount of drives configured. Specifically, anyone with drives in the double digits or more.
The grep would then still try to match "disk1", but if you have, say, 16 disks (including virtual ones for APFS stuff etc),
it would also match every other disk starting with "disk1", which is basically every disk above and including "disk10".
In your case, only disk13 and disk14 had an EFI partition, so that is why those two also appeared in your original output.
To fix this, we remove the open-endedness of the grep command by switching to
grep "$1s". This adds an "s" to every input string, so that "disk1" becomes "disk1s". macOS distinguishes partitions using the syntax
disk<num>s<partition>, so we can safely match using this method since we want to find a partition anyway. This cuts off the matching string after the actual number, preventing grep from matching anything other than the actual disk number. Thus the problem is fixed.
In typical development fashion, it all came down to a fix of literally a single character.
I would recommend we wait for Casey to take a look at the results and the proposed fix and once everything's greenlit, I think we should be good for using this script in setups with large amounts of disks safely.
I have already updated the script in my
original GitHub repository with this fix as well.