Photos lethal bug: non-repairable library corruption when click on Shared Album changes for standalone library, "The library could not be opened"

Nobody asks an Apple customer user why they despise Apple. There are so many reasons.

My latest reason to hate Apple is a bug in Ventura 13.6.1 Photos.app.

Click on Shared Album Activity for a standalone non-primary library and Photos crashes immediately.

After that when trying to open Photos.app initiates Library Repair -- but the repair fails with this unhelpful error message:

At this point I have only a dull Apple hatred because Apple's Aperture migration fiasco killed my hate glands.

After doing an option-command launch of the broken library macOS Ventura Photos.app first does a repair then does a full "Recovery". This takes a while but in my case it worked.

Don't click that Activity link.

Caveat: Monterey Photos.app failed to convert my Aperture Library so the conversion was done with Power Photos. So my Library may have some anomalies from that history.

Retiring domain associated with a DreamHost WordPress site - migrating site content to a new domain

I recently decided not to renew a domain managed and registered with DreamHost. That domain had an associated WordPress site. This is the sequence I followed to preserve the content of the site.

1. Turned off renewal for the domain (domain_old).
2. In WordPress for domain_old I exported the site as a XML file which I downloaded and archived.
3. In DreamHost control panel Manage Websites I clicked "new website". This let me add a subdomain to one of my existing domains.
4. In DreamHost control panel Manage Websites I clicked on domain_old and scrolled down to entry for Domain. That says "change your WordPress site to run under a different domain name". I chose the subdomain I created earlier. This took about 5-10 minutes to run.
5. When I then visited the subdomain I created the WordPress site came up.

The process only took a few minutes the first time I tried.

Downloading Facebook posts to document a trip

During a recent trip to Seoul South Korea I did a travelogue through Facebook posts about the odd sorts of things that interest me. I wanted to get them into a folder where I'm storying notes and information about the trip.

I found this worked reasonably well:

1. Follow Facebook's directions for downloading a copy of Facebook data.
2. Specify posts and the date range you want. If time zones are a factor you may want to go a day beyond what you'd expect. (The first download range ended Dec 15 when we left Korea, but that last day was not in the download. I suspect a time zone bug. I did it again specifying Dec 16.)
3. Specify HTML as a format and highest resolution images

I was notified the download was ready after about 30 minutes or so. The downloaded archive pages rendered in my browser. It's not a pretty layout but it has my text and images and comments on the images. It didn't include comments on the posts.

Canon DSLR doesn't show icon for remote control - you probably tried using the smartphone bluetooth connection

I have an old Canon DSLR, the EOS Rebel SL2. I think this post may also apply to other Canon DLSRs. 

If your remote used to work but now it doesn't, and the camera doesn't show the icon to enable remote control, chances are that you tried using the Bluetooth feature with a smartphone. You need to find the wireless setup part of your phone settings, then find the Bluetooth setting and turn it back to Remote.

The older cameras are kind of dumb, if you enable Bluetooth for your smartphone you disable the remote functionality.

Once you're fixed the settings issue you'll see the missing remote icon.

macOS OneDrive, ScanSnap PDFs and the "could not be opened" error in Monterey

When I migrated from Mojave to Monterey I ran into the typical array of macOS upgrade issues -- including having to reinstall Monterey. There's a reason I dread updating macOS.

One of the issues was that OneDrive didn't seem to work with my ScanSnap PDF uploads. In this case there were two suspects - the Monterey update and a OneDrive update. (One of the reasons I upgraded after migrating off Aperture was that OneDrive was no longer supported.)

The iOS ScanSnap client seemed to work as before, and the PDF appeared in the OneDrive folder I used -- but the file could not be displayed by Preview. I got a "could not be opened ... It may be damaged or use a file format that Preview doesn’t recognize."

It took a few searches to find the answer ...

If you were previously navigating to useraccount/OneDrive/DocumentFolder and opening your files from there, that seems to have stopped working now, and you have to go to Locations/OneDrive/DocumentFolder instead.

I'd had a Favorites link to the OneDrive folder that held my scans prior to the update. When I study where that link goes now it's not to the old file system folder, it's to:

/Users/jgordon/Library/Group Containers/UBF8T346G9.OneDriveSyncClientSuite/OneDrive.noindex/OneDrive/ScanSnap

So the folder that used to be in the file system was now buried in Library but the Favorite somehow resolved to it still.

I created a shortcut to a folder of the same name as displayed in Locations/OneDrive and the path there is

/Users/jgordon/Library/CloudStorage/OneDrive-Personal/ScanSnap

Digging into OneDrive preferences it claims my location is "/Users/jgordon/Documents/One..." (yep, truncated path). This is the path OneDrive used to use, but now there's just a Favorite there.  The true path is ... yep ...

/Users/jgordon/Library/CloudStorage/OneDrive-Personal/ScanSnap 

Even though none of the files are in a location that I expect Spotlight to index it does appear to index the files stored there once I revised settings so all files were downloaded. Once I did that however the file was now readable even in the location my old Favorite resolved to: 

/Users/jgordon/Library/Group Containers/UBF8T346G9.OneDriveSyncClientSuite/OneDrive.noindex/OneDrive/ScanSnap

 So this is kind of what I think was going on to cause this particular time wasting problem

1. Apple made everyone switch to their preferred approach to managing Cloud files.
2. The folders that were once in the local file system were gone, but an old Favorite somehow resolved to a similar folder buried in a virtual file system. The file, however, was no longer resident locally, it only seemed to be available if one inspected the virtual folder with Finder. Preview could not access it because it wasn't there, and in Monterey Preview gives a misleading error message.
3. When I used the Locations OneDrive "folder" to navigate I went to a different Library CloudStorage folder where OneDrive will auto-download folders on demand. If, however, full download is active (as it was previously so I can backup but that's not the default) then even the internal system OneDrive uses has a full copy and Preview will open it.

Apple wants all Document folders to be stored in the Cloud and may eventually want all user folders in the Cloud, so part of this is probably to prevent different Cloud Providers from cross-synching folders.

I think the bug hits those very few people who had a Favorite to an old style OneDrive folder prior to upgrading OneDrive. Although these kinds of complex emergent bugs don't hit many people, there are thousands of bugs like this so sooner or later we run into them. Which is why it's now very hard for non-geeks to use a personal computer.

Scripting Photos.app in Ventura (and maybe Sonoma) with AppleScript, Automator, and Shortcuts

[This post will be gradually developed. At the moment search engines return almost nothing on the current mess topic so even in its initial state it should be helpful.]

I recently moved my Aperture Photo Library from a machine running Mojave (last version OS with Aperture support) to one running Ventura and Photos.app. The migration was unspeakable.

Under Monterey there were a number of AppleScripts that mitigated key missing features in Photos (like batch rename). Some seem to ship from Apple with the OS. Others could be found online. Several appear in a compendium of user tips and scripts from Apple Discussions. But things have changed since Mojave and Monterey...

This blog post is going to be about scripting in Photos.app for Ventura and Monterey. In my own experimentation I was able to convert a 2019 Automator.app script containing AppleScript (basically it's a wrapper around a traditional AppleScript) into a Shortcuts.app script that runs as a service within Photos.app. To do this I had to enable AppleScript for use with Shortcuts and in Shortcuts details I could add it to the services menu. (Howard Oakley has an overview of the AppleScript to Shortcuts transition and an earlier article on Shortcuts in particular. The Shortcuts user guide article on this seems to have come from Automator but does actually work.)

I wasn't able to get the directions for adding Automator Quick Action Workflows in the Ventura Automator User Guide to work.

So I can batch rename images now from an entry in the Services menu. Yay.

If I find a good repository of Shortcuts I'll link to that. Otherwise I will try hosting them on my personal site or GitHub. I have an Apple Discussions question on the topic.

xt.local spam: Where it comes from, how to get rid of it

Recently more of the email that bypasses Gmail's spam filters has a return address with the suffix "*.xt.local". I've been able to find low quality posts about this issue from at least 2017, but in the past few months the volume has increased significantly.

One source of the emails has been spammer customers of Salesforce.

I'd previously marked one of these as spam, when I view it from inbox Google shows me: 

"You unsubscribed from <100018015.xt.local>"

If I try to reply I see:

"reply-fec215727d600275-157_HTML-100984021-100022017-13039@e.sixt.com"

If I choose to filter I get this as a filter criteria

Has the words: list:(<100018015.xt.local>)

An expert on spam filtering tells me xt.local is the name of an email list. 

I've added xt.local to Gmail's (increasingly obscure) filters as an automatic delete. I currently have it in there as a return address but if that doesn't work I'll try it as a label. 

Google's 'show original' extracts the following header information:

.... 

From: SIXT <info@e.sixt.com>

To: ********

Subject: Start your week in style! Up to 30% discount on midweek rentals

SPF: PASS with IP 13.111.115.170 Learn more

DKIM: 'PASS' with domain e.sixt.com Learn more

DMARC: 'PASS' Learn more

I'll update this post if filtering on xt.local as the sender address doesn't work.

PS. When I searched on this, even using Kagi (which is looking to be a very interesting search engine if they can stay in business), I found very few useful posts. Even five years ago there would have been dozens. Something rather important has been broken.