Checksums ... ;-)

Apple Mail is the best of breed for inter-application communication. Most other email clients, including Thunderbird, do not provide such functionality.

In the Finder, press Command-Shift-G and paste: ~/Library/Application Support/DEVONthink 3 . When you open a support ticket, please attach the Console.log.

2 Likes

Whatever Apple Mail can do what others cannot do, it should not lead to an Application that is unable to open a support ticket, right?

To be honest, I am not sure if other Apps can open ThunderBird instead, but the canonical way is to open a website where the support email adress is given and the pathes to requried logfiles.

Command-Shift-G … I needed to search that:
Just enter the folder “~/Library/Application Support/DEVONthink 3”

I checked this file and did not see nothing about sync problems, but then found the Cloudy.log file in a subdirectory with “find” and found some hints that I am following now.

Will report back

Very interesting.

I get such error messages:

2022-11-21 23:01:54,726 ERROR: Error Domain=NSCocoaErrorDomain Code=513 "“IMG_0001.png” couldn’t be moved because you don’t have permission to access “ARCHIVES”." UserInfo={NSDestinationFilePath=/Volumes/DT_MAIN/ARCHIVES/IMG_0001.png, NSUserStringVariant=Move, NSFilePath=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 5301/Main Thread/8/IMG_0001.png, NSUnderlyingError=0x60000c13fae0 {Error Domain=NSCocoaErrorDomain Code=513 "“IMG_0001.png” couldn’t be copied because you don’t have permission to access “ARCHIVES”." UserInfo={NSSourceFilePathErrorKey=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 5301/Main Thread/8/IMG_0001.png, NSUserStringVariant=(
    Copy
), NSDestinationFilePath=/Volumes/DT_MAIN/ARCHIVES/IMG_0001.png, NSFilePath=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 5301/Main Thread/8/IMG_0001.png, NSUnderlyingError=0x60000c13e880 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}}

So, DT cannot access /Volumes/DT_MAIN/ARCHIVES

But I can do so with my terminal shell:

(base) tja@mini:/Volumes/DT_MAIN/ARCHIVES$ ls
total 24
drwxr-xr-x  1 tja  staff  192 Jul 30 23:17 archive/
drwxr-xr-x  1 tja  staff  416 Jul 30 23:17 DO_NO_DELETE/
drwxr-xr-x  1 tja  staff  160 Jul 30 23:17 BACKUPS/
(base) tja@mini:/Volumes/DT_MAIN/ARCHIVES$ touch test
(base) tja@mini:/Volumes/DT_MAIN/ARCHIVES$ ls
total 24
drwxr-xr-x  1 tja  staff  192 Jul 30 23:17 archive/
drwxr-xr-x  1 tja  staff  416 Jul 30 23:17 DO_NO_DELETE/
drwxr-xr-x  1 tja  staff  160 Jul 30 23:17 BACKUPS/
-rw-r--r--  1 tja  staff    0 Nov 21 23:06 test
(base) tja@mini:/Volumes/DT_MAIN/ARCHIVES$ rm test

And DT also could do this, before.

So, I checked the “Full Disk Access” security setting and DT is contained there!

Currently, I have no idea what exactly is preventing DT to access this and other folders.
I mean, that worked before!

Next, I created an empty “testfile.txt” from within DT - and this got created correcty!

(base) tja@mini:/Volumes/DT_MAIN/ARCHIVES$ ls
total 24
drwxr-xr-x 1 tja staff 192 Jul 30 23:17 archive/
drwxr-xr-x 1 tja staff 416 Jul 30 23:17 DO_NO_DELETE/
drwxr-xr-x 1 tja staff 160 Jul 30 23:17 BACKUPS/
-rw-r–r-- 1 tja staff 0 Nov 21 23:18 testfile.txt

(Create within DT over Right Mouse menu “New / Plain Text”

So it is not DT itself that as missing permissions!

Not sure whether I’ve read it in this forum, but there seems to be a bug in macOS Ventura regarding Full Disk Access. You might want to search for it.

2 Likes

Here’s the post, not sure whether it has something to do with your problem though.

2 Likes

Many thanks, but I am careful with major updates and am still at Monterey 12.6

I am sure that this behavior is relatively new …

Sadly, the Sync.log file has only lines back to 2022-11-16 and there I can already see such “no access” messages, so this is happening since at least 5 days.

Here the first log entry:

DEVONthink 3 3.8.6, DEVONcloudy 1.20.7, macOS Version 12.6 (Build 21G115)

2022-11-16 20:52:53,528 ERROR: Error Domain=NSCocoaErrorDomain Code=513 "“IMG_0096.PNG” couldn’t be moved because you don’t have permission to access “New”." UserInfo={NSDestinationFilePath=/Volumes/DT_XXX/New/IMG_0096.PNG, NSUserStringVariant=Move, NSFilePath=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 4388/Main Thread/1/IMG_0096.PNG, NSUnderlyingError=0x600009c226a0 {Error Domain=NSCocoaErrorDomain Code=513 "“IMG_0096.PNG” couldn’t be copied because you don’t have permission to access “New”." UserInfo={NSSourceFilePathErrorKey=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 4388/Main Thread/1/IMG_0096.PNG, NSUserStringVariant=(
    Copy
), NSDestinationFilePath=/Volumes/DT_XXX/New/IMG_0096.PNG, NSFilePath=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 4388/Main Thread/1/IMG_0096.PNG, NSUnderlyingError=0x600009c20930 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}}

Thanks, going to read this!

Meanwhile, I opened a support ticket (over the link from @BLUEFROG above)

I did as recommended in this article and removed DT from Full Disk Access, then started it again - and I got asked to give DT access to Network Volumes, which I gave.

Also, I added it again to “Full Disk Access” …

Sadly, the problem remains.

And then I tested again:

Created a new text file from DTTG in the above …/ARCHIVE group:

It got uploaded to WebDAV and … bammmm… it also showed up fine in DT:

Screenshot 2022-11-22 at 00.04.27

So, the problem only exists for certain file types, but not for others.
Very strange.

But DT can indeed download new files from WebDAV and write them to the indexed folders - just not for every content.

Did you check the ownership & permissions of the folders? Sometimes a permission issue is just a permission issue. You could also enable the option to ignore the ownership on the network volume.

I think I proved that this is not the problem:

As the logged in user, both a terminal shell and DT can write to the folder!
The permissions are also visibly OK and there are no ACLs that could be a problem.

DT can write itself to the target folder, when creating a new file from within DT!

And DT can write new files that it get’s over WebDAV when such a new file is created on an iPad (and uploaded to WebDAV).

But it does not work for all type of files, as it seems - of course the technical explanation may be different.

All of this was shown in my above text-snippets and screenshots.

DT strongly says, that there is no permission to access the folder “ARCHIVE” while it can write to it without problems for new textfiles - regardless of how it get’s added (by creating from DT or by creating over WebDAV from an iPad)

What excactly do you mean by this?

Anyways, DT can write to it!

Well, that’s at least the error returned by macOS. Therefore it’s either a wrong error message or maybe a temporary issue of the WebDAV server, e.g. maybe due to concurrent access by multiple devices.

I don’t know how to repeat this in a way that is more clear…

DT can add lots and lots of files coming from WebDAV without any problem at all.
There is no problem with WebDAV!

DT can also see all of the WebDAV files (as the names and sizes are shown) and it can download the WebDAV files - but only to some cache folder and then cannot move them to the destination folder:

At least, the log files says that the file got download to “NSSourceFilePathErrorKey=/Users/tja/Library/Caches/TemporaryItems/DEVONcloudy 12795/Main Thread/360/IMG_0001.png”

Also, DT clearly has the rights required to do this - as tested with textfiles:

Created on an iPad, the files get uploaded to WebDAV and DT on the Mac perfectly fine downloads them to the indexed folders!

This problem is strange but seems to be a local DT problem!
Or, of course something from macOS.

Meanwhile, I also rebooted the Mac just to be sure … no change

To prove that the download from WebDAV works, I let this run:

(base) tja@mini:~$ while ! ls /Users/tja/Library/Caches/TemporaryItems/DEVONcloudy\ 12795/Main\ Thread/* 2>/dev/null ; do : ; done
total 400
-rw-r--r--@ 1 tja  staff  201443 Nov 22 14:38 IMG_0001.png
(base) tja@mini:~$

As you can see, the loop exited when the PNG file was correctly downloaded from WebDAV to the cache folder!

But DT cannot move it to the destination folder, as it says in the logs.

A network volume mounted in the Finder is actually not the same as directly accessing a WebDAV server (like the synchronization does). Did you also check the permissions of /Users/tja/Library/Caches/TemporaryItems/?

1 Like

Also, to show this again, I added 2 more files to DTTG:

So, they got added on iPad…

And then, looking on DT:

They appeared without problem!

But NOT the PNG files…

Per terminal:

(base) tja@mini:/Volumes/DT_MAIN/ARCHIVES$ ls
total 48
drwxr-xr-x  1 tja  staff   192 Jul 30 23:17 archive/
drwxr-xr-x  1 tja  staff   416 Jul 30 23:17 DO_NO_DELETE/
drwxr-xr-x  1 tja  staff   160 Jul 30 23:17 BACKUPS/
-rw-r--r--  1 tja  staff     5 Nov 21 23:58 createdByDDTG.txt
-rw-r--r--  1 tja  staff  1087 Nov 22 14:38 daily_dates.log
-rw-r--r--  1 tja  staff  1681 Nov 22 14:38 rsync_XTRMQ-T7_Touch2TB.sh

Yes, please see above - the PNG get’s correctly downloaded to the cache folder!

But it cannot be moved - while other downloaded files can get moved!

Very strange

@BLUEFROG
@cgrunenberg

I found the problem!

First, how I did this:

I let a loop run to wait for DT to download a file from WebDAV and copied it to ~/TMP

(base) tja@mini:~$ while ! cp -p /Users/tja/Library/Caches/TemporaryItems/DEVONcloudy\ 12795/Main\ Thread/*/* ~/TMP/ 2>/dev/null ; do : ; done

This produced the following file:

(base) tja@mini:~$ ls ~/TMP/IMG_0001.png
-rw-r--r--@ 1 tja  staff  201443 Nov 12 20:35 /Users/tja/TMP/IMG_0001.png

Now, I just tried to simulate what DT would be doing:

(base) tja@mini:~$ mv ~/TMP/IMG_0001.png /Volumes/DT_MAIN/ARCHIVES/
mv: /Volumes/DT_MAIN/ARCHIVES/IMG_0001.png: unable to move extended attributes and ACL from /Users/tja/TMP/IMG_0001.png: Operation not permitted

This gives a harmless error message, because the target file system cannot handle those unimportant ACLs or extended attributes …

The “mv” did work, of course:

(base) tja@mini:~$ ls ~/TMP/
total 0

(base) tja@mini:~$ ls /Volumes/DT_MAIN/ARCHIVES/
total 448
drwxr-xr-x  1 tja  staff     192 Jul 30 23:17 archive/
drwxr-xr-x  1 tja  staff     416 Jul 30 23:17 DO_NO_DELETE/
drwxr-xr-x  1 tja  staff     160 Jul 30 23:17 BACKUPS/
-rw-r--r--  1 tja  staff  201443 Nov 12 20:35 IMG_0001.png
-rw-r--r--  1 tja  staff       5 Nov 21 23:58 createdByDDTG.txt
-rw-r--r--  1 tja  staff    1087 Nov 22 14:38 daily_dates.log
-rw-r--r--  1 tja  staff    1681 Nov 22 14:38 rsync_XTRMQ-T7_Touch2TB.sh

So, the file is where it should be.

The only explanation for this is, that DT “interpretes” the apparent error message from the move, because of the missing ACL / extended attribute support und simply removes this file again!

This is very frustrating, as I see no way to fix this by myself!
Files from anywhere may have added ACLs / extended attributes… and I have no way of removing them.

Only an option to DT that allows to ignore ACLs / extended attributes or ignores the error messages from “mv” could help.

I cannot change the fact that some files come with some ACL / extended setting - but I have no interest in them!

Any chance for such an option to DT?
Any other idea how to fix this?

Many thanks