Moving DOP files with Sequoia

Up until recently, I would transfer RAW and DOP pairs from another Mac to mine.

As long as I open the RAW in PL, everything seems fine. But, as sometimes happens, I want to examine the DOP using TextEdit, Sequoia’s “new/updated” quarantine mechanism tells me that the DOP could contain dangerous code and refuses to open it, advising me to trash it.

Effectively, the file has been marked with the com.apple.quarantine xattr flag. Now I can imagine why - because it contains what looks like LUA code.

Without resorting to using the Terminal to delete this flag, if I open the image file in PL, and explicitly (re)write the sidecar, the issue is resolved and the file will now open in TextEdit.

This looks like apple are getting hyper-vigilant to the point of preventing folks doing things that have been doing for years.

After exhaustive tests, I can state that the quarantine flag is only applied when a DOP file (or any other) lands on my machine from somewhere else and before PL has ever touched it. It is definitely not a PL problem.

That’s pretty much what every security enhancement is. We used to send passwords in plain text over the internet for years.

I used to look after folks’ computers and software and would often find Post-it notes on monitors. Then there was Sage accounting software, whose default password was “letmein”. It was astounding how many folks never changed it.

1 Like

I just wonder why you didn’t get that warning with PL.

George

Because DOP is an authorised file type for PL and it is opened from within the app with appropriate permissions.

Is this warning not from the OS?

George

Yes it is. Minimum 20 chars

I don’t know what that minimum 20 chars mean.
Bu if it’s a message from the OS and gives you only the ability to delete it or just stop the action in this case why doesn’t it showing up with PL?

George

The forum requires at least 20 characters, even though I only wanted to say “yes it is”.

Stupid I didn’t recognize that problem. :grinning:

George

Joanna, which Sequoia are you using? I am on 15.2 and don’t see the weird quarantine behavior.

If you don’t want to edit the file and merely view it, finder should show you a preview simply by hitting space bar when you are focused on the file.

Here’s a piece on the quarantine flag that may be helpful –

The problem comes when you copy the DOP file from one computer to another.

How is the copy performed?
Point to point adhoc?
Via a server or storage media in between?

I just use Finder to drag the file from one computer to the other.

I also get the dreaded message from macOS Sonoma 14.7.5

I’ve never seen this popup before and I get the feeling that it was added in the update from 14.7.4 to 14.7.5

I usually getting the :fu: when I do the following:

  • select a .dop file
  • open and close it without edits with Hex Edit (App Store)

I have sent a message to Apple about this. They usually don’t reply, but I hope that they get floods of such messages, after all Hex Edit is from the App store!


I found another issue a few days ago which is new and possibly related

When I download images from an SD card using the iMac’s SD card slot, the card is not recognised by my camera (EOS R7, Firmware 1.6) afterwards, the card cannot be formatted either, so it looks like a complete loss.

Pick one of the following measures to work around this issue:

  1. Write protect the card before inserting into the Mac card slot
    → This has always worked so far

  2. Switch card slots when re-inserting into the camera
    → Seemed to work so far, but doesn’t make sense somehow

  3. Delete the hidden .fseventsd folder before ejecting the card from the Mac
    → This has always worked so far

I’ve used firmware 1.6 before updating macOS 14.7.4 and have never had this issue. Looks like an incompatibility between macOS 14.7.5 and R7 Firmware 1.6!


A few trials later, I cannot reproduce the issue.

Here’s some interesting behaviour.

I select a DOP file on the other computer _HLN0006_DxO.tif.dop and examine it in Terminal…

helensummers@MacMini Desktop % ls -l@ _HLN0006_DxO.tif.dop
-rw-r--r--@ 1 joannacarter  staff  114215 30 mai  2024 _HLN0006_DxO.tif.dop
	com.apple.lastuseddate#PS	    16 

On copying it to my computer, I do the same…

joannacarter@MacBookPro Desktop % ls -l@ _HLN0006_DxO.tif.dop
-rw-r--r--@ 1 joannacarter  staff  114215 30 mai  2024 _HLN0006_DxO.tif.dop
	com.apple.lastuseddate#PS	    16 
	com.apple.quarantine	    29 

Note the addition of the com.apple.quarantine flag.

This file refuses to open in TextEdit, giving this dialog…

However, if I simply copy it and rename it to _HLN0006_DxO.tif.txt, then I have absolutely no problem opening it in TextEdit, even though Terminal gives me…

joannacarter@MacBookPro Desktop % ls -l@ _HLN0006_DxO.tif.txt
-rw-r--r--@ 1 joannacarter  staff  114215 30 mai  2024 _HLN0006_DxO.tif.txt
	com.apple.lastuseddate#PS	    16 
	com.apple.quarantine	    29 

… complete with the same quarantine flag. And this opens without problem in TextEdit.

Now, if I open the image file to which the DOP belongs, create a virtual copy and then close it, Terminal now shows that the com.apple.quarantine tag has been removed.

Closing PL and attempting to open the DOP file in TextEdit now succeeds.

Further research shows that the contents of a PL DOP file are, essentially, a Lua script. Maybe this is the reason that macOS detects it as an executable script and thus quarantines it.

Now, if I can only find a .plist file or similar that makes that assumption, maybe I can break the association.

Check out spctl. It seems to manage these things as far as I can understand from its man page.

NAME
     spctl – SecAssessment system policy security

SYNOPSIS
     spctl --assess [-t type] [-] file ...
     spctl --global-enable | --global-disable
     spctl --enable | --disable | --remove [-t type] [--path path] [--requirement requirement] [--anchor hash] [--hash hash]
     spctl --status

DESCRIPTION
     spctl manages the security assessment policy subsystem.

I once managed to corrupt a single image by opening it in Photomator on my iPad, directly from the card .its a “non-destructive” edit, but clearly something was written to the card and the original image became unreadable by any software on iPad or Mac.

My normal process is to let LR copy the files off the card after which it automatically ejects it. I’ve never had a problem with this.

Same thing here, but things have changed lately. I’l try to find out what might be the cause and the current suspects are the update to macOS 14.7.5 and version 1.6 of the R7’s firmware. I did these updates a few weeks ago, but my main suspicion is with macOS’s increasingly neurotic/tight security.

The cards could be the problem too, but they have been used mildly so far.


A few trials later, I cannot reproduce the issue.
:roll_eyes: