Annotation marked Custom Access when formatted rtfd

I don’t know which of the following steps actually causes this, but here’s what I know so far:

  1. create file (tested with both pdf and plain text)
  2. add some text to that file (I used the words New file)
  3. in the Annotations and Reminders inspector, create an annotation by selecting new from template/default annotation
  4. leave the default text in situ
  5. drag a photo from the Photos app to the annotation (you will receive a notice that the photo has been exported in lower resolution)
  6. find the annotation in the annotations folder
  7. from the context menu select Show in Finder
  8. in Finder, from the context menu of the annotation file select Get Info
  9. you will see the annotation is in rtfd-format rather than rtf (because it contains an image)
  10. 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.
  11. 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?

Which version of macOS do you use? Because DEVONthink just uses macOS’ default handling of permissions but doesn’t change them on its own.

Big Sur 11.2.3 (20D91)

using ls -l I can see that the two files making up the rtfd are marked -r--r--r-- rather than -rw-r--r-- like the other files.

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)

Works fine on 11.3beta (Intel). Where is the database located?


Jim keeps telling me not to use beta software in a production environment, so I can’t confirm that :smiley:

And does this happen in case of a new database too?

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.

Just tried it on 11.2.3 (M1) too, also no issues. What are the permissions of the database and its enclosing folder?

drwx------ for the enclosing folder and
drwxr-xr-x for the unencrypted database and
-rw-r--r-- for the encrypted databases

I’m on an Intel Mac; are you working as a User or as an Admin?

Did you test this using encrypted databases? I used regular databases and an admin account.

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.

Don’t have a regular account right now on Big Sur but on Catalina it makes no difference - owner can read/write, staff & everyone else only read.

Mind - that’s exactly what it says here too, but it’s not actually the case. The important information is above that field:

Screenshot 2021-03-23 at 14.51.11

See how it says “You have custom access” rather than “You can read and write”?

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 :see_no_evil:

Can I exclude just rtfd from a smart rule (is that what “formatted note” is?)?

No, a formatted note is a type of HTML file. RTFD is still rich text.
You could try this…

Thanks Jim :slight_smile: @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 :+1: