krnl386

400ppm? That’s pretty hard water. Your espressos must taste awful. 😣

If you’re that worried, why not run chmod -R u+w .git inside the project dir to “un write-protect” the files, then just ascend to the directory containing the project dir (cd ..) and use rm -r without -f?

The force flag (-f) is the scary one, I presume?

Wow, beautiful analogy! I’m going to use that in my professional career if you don’t mind. Also with your permission I’d like to give you credit with a link to this comment, if that’s OK with you, of course.

I wonder if this has anything to do with Apple’s CSAM scanning. You know, hang on to the photos as evidence, and, for an added bonus, sell more iCloud storage because the “System Data” now exceeds the free iCloud data storage quota. Win-win!

If it is indeed a boneheaded mistake, then it’s probably because of over reliance on RPC-type calls from the front-end that displays the data, to the back-end that actually handles the data. User deletes photo, and the front-end, instead of actually deleting it, tells the backend to do it… and then hides the photo from view, maybe updates its index of photos marking them as “deleted” regardless of whether the backend actually deleted the photo.

Then an OS update comes along, and rescans the filesystem, and report a bunch of new photos to the front-end, that then happily add them to the GUI to the user’s surprise.

Modern APIs and software architectures are a bloated, unnecessarily complex mess, and this is the result.

Wasn’t Google Plus used to be called Circles? Man, I feel old!

5 days WFH hands down.

Good point! I assumed the worst; but it’s possible the array is rebuilding or even already rebuilt and just needs to be mounted.

According to LocalSend docs these are the ports that need to be opened: Multicast (UDP) Port: 53317 Address: 224.0.0.167 HTTP (TCP) Port: 53317 AFAIK macOS firewall is app-based, at least in the GUI. So depending on how you installed LocalSend, you may have to add it to the list of allowed apps: https://support.apple.com/en-ca/guide/mac-help/mh34041/mac

You may be able to add the ports above to /etc/pf.conf manually, but AFAIK messing with pf on macOS is not recommended.

The other thing I wanted to ask is about Vallum. If you have it running on that Mac, would it not “take over” the macOS firewall?

Assuming you were using a Linux software RAID, you should be able to recover it.

The first step would be to determine what kind of RAID you were using… btrfs, zfs, mdraid/dmraid/lvm… do you know what kind you set up?

To start the process, try reconnecting your RAID disks to a working Linux machine, then try checking:

1. The sudo lsblk command will help you get a list of all connected disks, sizes and partitions.
2. The partition tables on the disks, eg: sudo fdisk -l /dev/sda (that’s a lowercase L and /dev/sda is your disk)
3. Assuming you use a standard Linux software RAID, try sudo mdadm --examine /dev/sda1. If all goes well, the last command should give you an idea of what state the disk is in, what RAID level you had, etc.
4. Next, I would try and see if mdadm can figure out how to reassemble the array, so try sudo mdadm --examine --scan. That should hopefully produce output with the name of the RAID array block device (eg, /dev/md0), RAID level and members of the RAID array (number of disks). Let me know what you discover…

Note: if you used zfs of btrfs, do not do steps 3 and 4; they are MD RAID specific.

That is how you learn! Actually one of the best ways to learn, IMHO.

Ah, that would break things! Any idea how the incorrect UUID got into the kernel boot parameters?