I don’t know which of the following steps actually causes this, but here’s what I know so far:
create file (tested with both pdf and plain text)
add some text to that file (I used the words New file)
in the Annotations and Reminders inspector, create an annotation by selecting new from template/default annotation
leave the default text in situ
drag a photo from the Photos app to the annotation (you will receive a notice that the photo has been exported in lower resolution)
find the annotation in the annotations folder
from the context menu select Show in Finder
in Finder, from the context menu of the annotation file select Get Info
you will see the annotation is in rtfd-format rather than rtf (because it contains an image)
in the Sharing & Permissions section, the heading will be “You have custom access” rather than “You can read and write” as is the case for all other annotations which are saved in rtf, rather than rtfd format.
the Names & Privileges listed below that entry are identical in both this annotation and any other in rtf rather than rtfd format
(addendum: I have tried the same steps, but adding an image dragged from Finder rather than from Photos; the result is the same)
Why are these annotations being created with “custom access”? (and what does that even mean?) These files are not accessible in the same way as others which are marked “you can read and write”, despite my being the owner and having “Read & Write” privilege. Some software - including shell script "/usr/bin/openssl sha1 " & quoted form of thePath cannot access the file, producing a read error.
I’m happy to provide more details (and @cgrunenberg I’m going to send you the read error message unredacted by PM in just a moment); presumably there are more details on the file permissions available via the terminal?
if I do chmod u=rw,g=r,o=r on the file, the file permissions are then drw-r--r-- which correlates with the error message I sent you; it would seem the rtfd files are being treated as directories? I can now also no longer open the file with text edit (it’s in my test database so no harm done)
Yes; I’ve just checked on a brand new, otherwise empty database (unencrypted, same location as above) and the same phenomenon occurs.
I’m happy to wait for 11.3 to see whether I can reproduce the error then; in the meantime perhaps somebody else on 11.2.3 might have a moment to try out the steps I outlined and see if they have the same problem. I’m on a “User” rather than an “Admin” account on macOS btw.
Both encrypted and unencrypted, the results are the same. So the obvious difference between your tests and mine, at the moment, is that you are using an admin account; I could well imagine that that makes the difference. I don’t have a test rig which I can set DT up on for use with an admin account.
And which permissions does a RTFD created with TextEdit in the same path have? Does this cause any issues at all apart from the confusing description in the Finder’s Info panel? Maybe it’s just a UI glitch of Big Sur.
Interesting; rtfd files created by text edit exhibit the same behaviour, regardless of where I store them. Is this inherent to rtfd, maybe? So is the attachment maybe inhibiting openssl from processing the file (because, factually speaking, it is not one file)? And the same for some other software which can’t deal with the file (and also reports a read error due to a rights violation).
Whatever the case, it’s obviously nothing to do with DT
Can I exclude just rtfd from a smart rule (is that what “formatted note” is?)?
Thanks Jim @cgrunenberg I apologise for wasting your time this afternoon; I should have tested the behaviour of an rtfd outside of DT before assuming this issue had to do with DT itself. Thank you for your support and pointing me in the right direction