Truly deleting ‘removed’ files from Lightroom

When you tell Lightroom to deleted rejected photos, it pops up a dangerous dialog box:

Screen shot of Lightroom dialog asking if you want to actually delete rejected photos, or merely lose track of them

Though it does explain itself well – i.e. if you want to actually delete the photos, you need to click “Delete from Disk” – the default option is that misleading “Remove” button, which doesn’t really remove the files at all – it merely makes Lightroom lose track of them. They’ll still be there on disk, wasting space forever.

And, you can’t directly undo this operation, so if you hit return a little too quickly, or misread the dialog at any point, you’re seemingly pretty screwed (if you have a Lightroom catalog of any significant size).

Luckily, there is a way to find these undead files – that doesn’t require you walking through every single file on disk one by one & comparing against Lightroom’s view of the world.

1In the left-side panel, under the “Folders” section, select all the folders and right-click on them (if you have multiple volumes listed under “Folders”, you’ll have to do this one volume at a time as Lightroom won’t let you select folders across multiple volumes simultaneously). You’ll get a contextual menu:

Screen shot of the contextual menu from right-clicking on an entry in the 'Folders' section of the Lightroom left-side panel

2Click “Synchronize Folder…”. A dialog will appear:

Screenshot of the "Synchronize Folder" dialog

You probably want to uncheck “Remove missing photos from catalog” (if it’s not already disabled) and “Scan for metadata updates”, as those are unrelated to the purpose here and have their own ramifications. Instead, just select “Import new photos” and “Show import dialog before importing”. Then, click “Synchronize”.

3Lightroom’s standard import dialog will now appear, and will slowly sort through all the files in the folder(s) you selected, filtering them down to just those that exist on disk yet are not tracked in Lightroom – e.g. all those rejects you accidentally “Removed” but didn’t really remove previously. You can now review those and see what you’ve got – it’s possible you’ll find in there media you didn’t intend to delete, but rather were somehow misplaced by Lightroom at some point.

You might want to, in the import dialog, change your preview generation setting to ‘Minimal’ in order to minimise import time & wasted preview generation. You could also choose to add some keywords to the imports, e.g. “to be deleted” or “recovered” or “undead”, if you’re not going to just immediately delete them anyway.

In any case, you can now import some or all the undead files. Importing them might seem counter-productive, since the goal here is to delete them – but it’s necessary for the final step…

4Once they’re imported, you can now immediately mark them as rejects and delete all rejects again – this time correctly choosing “Removing from Disk”.

So while it’s a bit roundabout, it does get the job done pretty quickly and easily. Now if only Lightroom would fix that stupid dialog to make the default option the one that actually does what you told Lightroom to do to begin with. 🙄

Full Disk Access is required to access Time Machine backups in Mojave

I’ve been struggling since Mojave came out to deal with it’s over-bearing expansion of SIP (“System Integrity Protection”), which is basically a super-root notion that blocks access – even to root – to lots of basic parts of the system, including obvious & mostly sensible ones like /System and /Library, but also less usefully things like any & all Time Machine backups.

Blocking access to Time Machine makes it very difficult to actually use Time Machine, since it’s then difficult to retrieve files from a backup (you have to then use the stupid ‘warp’ Time Machine interface, which is slow, ugly, and buggy).

Luckily, it turns out there is a fairly simple solution that isn’t disabling SIP entirely (which requires multiple reboots in order to do, so is typically quite disruptive & slow). It appears that any application granted Full Disk Access (System Preferences → Security & Privacy → Full Disk Access) can read Time Machine backups.

In case you’re unfamiliar, the symptoms of this problem include:

  • Being unable to navigate into Time Machine backups in the Open / Save / etc dialogs.
  • Being unable to see – through ls or similar tools – the contents of Time Machine backups via Terminal.
  • Apps reporting errors like “The file “Foo” couldn’t be opened because you don’t have permission to view it” or bluntly “Operation not permitted” when trying to read something in a Time Machine backup.

There’s a strange & ironically very bad security quirk though – curiously, any tools run via Terminal inherit Terminal’s access (or lack thereof) to Full Disk Access. They don’t use whatever setting might be specified for them in the Security & Privacy preferences. This is pretty baffling, as it means to give Full Disk Access to anything you run via Terminal, you have to give it to everything you run via Terminal. Anything you specifically give Full Disk Access won’t actually receive it if it happens to be launched via the Terminal (which confused me for a while, since it’s so unintuitive).

I’m guessing whatever mechanism enforces all this so-called security is based in LaunchServices or somesuch – while the Finder and most things in general will launch apps via LaunchServices, as detached & independent process sessions, Terminal doesn’t – everything it runs, from the shells down, run under it in the process hierarchy, and seemingly share its security & privacy settings.

Blink XT review

Normally I’d just post a review like this on the merchant’s website – in this case Amazon.  Yet perplexingly when I tried to do so, I was given the error message:

Sorry, we are unable to accept reviews for this product. This product has limitations on submitting reviews. There can be a number of reasons for this, including unusual reviewing activity.

Hmmm… curious.  I tried revising my star rating from 2 to 5 to see if it were so blatantly influenced by that, but it did not make a difference.

Anyway, FWIW here’s my review:

First up, the Blink XT cameras do not work with normal batteries – you have to buy quite expensive Lithium batteries.  Use of any other types of AAs will result in the camera not triggering reliably, failing to record full videos (or at all), etc.  So factor in about $20 extra per camera for a pair of such batteries.  Also, the two year quoted battery life appears to be a joke – I had to replace the first set of batteries after only a month or so.

Second, the video quality is not great.  They’re ostensibly 1080p but it looks both upscaled (probably from 720p) and it appears the video is recorded on the sync dongle, not the camera itself, so it’s subject to any radio interference issues that might exist, which will result in noticeably degraded video quality – or recording corrupting or cutting out entirely.  Overall the video quality, even in the best case, is like that of a very cheap smartphone (as of 2018), or say a 2010 iPhone.

Third, the only way to remotely control the cameras, and view recorded videos, is via mobile apps.  No desktop apps, no website, nothing.  So it’s very tedious to view the recordings, manage them, etc.

Fourth, the mobile app for iOS is not great.  It’s very slow – Cloud-saved videos are never loaded in advance, only on demand, and can take up to a minute to start playing.  It’s also a bit buggy.  e.g. a lot of the time it’ll fail to do whatever you asked, responding instead with a long delay ended with an error message along the lines of “the camera is busy”.

Fifth, wireless range is limited – I have one camera only about ten metres from both my wireless router & the sync module, through one exterior wall, and the video quality is noticeably degraded sometimes.  I tried placing one camera with line of sight about 30 metres away, and it worked (barely) for an hour or two and then never again, until I moved it much closer.

Sixth, motion triggering is inconsistent and lacks important configuration options (like zoning to denote areas to ignore or conversely to focus on).  e.g. for one video looking out the front of my place, it unavoidably has the street in view, which means that even on minimal sensitivity, we get a video & notification every single time a car goes by on the street.  Yet it still won’t reliably trigger when a human walks up to the front door, until they’re right in front of the camera.  Yet it’s nonetheless sometimes triggered by squirrels up to 10 metres away.

So, solidly not recommended.  Not the worst thing ever – the system does function in a very minimal sense, and I’ve managed to get some utility out of it, but it’s definitely disappointing – and many of these errors could surely be easily fixed by better software, firmware, or hardware design (e.g. support for normal batteries).