Some opaque issue around Finder operations & system folders behavior (implicating DT4)

I saw this before, when I copied / moved some files via Raycast – somehow they ended up in the DT Inbox. :open_mouth:
I was totally buffled. :open_mouth: :open_mouth:
Then, I thought this must be a Raycast problem. :thinking:

Just now, I re-experienced a similar phenomenon at a much more unexpected place:
I was in Peakto (a Meta MAM for photos + videos). Needing to access its log files, I activated the submenu “Peakto > Developer > Locate Peakto Log Files”…
… what followed was an attempt to import this into DT4. Or at least it was firing up DT4 for no obvious reason. :open_mouth:

Seeing this in awe, I remembered the first experience reported above.
So, I disabled Raycast to be sure and triage the problem a little.
Result: same behavior w/ Raycast turned off.
Hitting that menu activates DT4 :open_mouth:
– and it looks like it wants to imports something in the inbox (like in the initial case of moving finder files via Raycast) :open_mouth: :open_mouth:

Any ideas?

There is nothing built into DEVONthink that would cause such behavior.

Hitting that menu activates DT4 :open_mouth:

What menu ? And are you pressing keys or selecting a menu command with your mouse/trackpad?

A wonder whether the shortcut of a service caused this.

Yeah, that’s what I was thinking as well.

I clicked this directly in Peakto w/ Mouse.
It is strange.
And as described, first I thought something (Raycast?) is inserting it in the process. But then, as described, I was baffled when DT fired up – even when both DT and Raycast were closed. All this happens directly from the Menu interaction w/in Peakto.

I can´t figure any service getting into this, as it´s direct (mouse)interaction w/ the mentioned menu, and even triggering DT, when not active before.

Of course, I am happy to send a video. But not sure this adds anything.
Do you have an idea how to possibly trace this?

TIA

This is what I can find, with the limited knowledge I have about how to possibly hunt this down:



As far as I can see, the Peakto logs end up in the DT inbox index. But, at the same time they are considered missing. A riddle to me.
Both. How should they get there in the first place? Why are they simultaneously missing and not to be found via the DT search?
As, when I am searching the DT Inbox for “Peakto”, where DT seems to be expecting them, nothing shows up. (3rd screenshot)

Again, I am a total loss of what´s going on here…

PS: I also contacted Cyme from Peakto as to whether they have an idea what is possibly going on here…

Happened to me (Blushing). By accident, using CustomShortcuts. I entered a cmd-something accidentaly, without realizing. I was probably typing in some other application, but CustomShortcuts must have come to the front and was listening. Always good to browse these types of apps for an updated shortcut inventory.

Thx for chiming in with your experience, @uimike!

I of course see that as a logical hypothetical explanation.

But how / why should this happen when I mouseclick on the menu of another app (Peakto)?

Alternatively, the only pathway to this kind of behavior I can fathom, is that the developer error logs from Peakto somehow got imported accidentally into DT inbox beforehand. and now the Peakto menu command to the logs “finds” them in the DT index…?
But, again: I would have no idea how a) this should come about technically (clicking the menu item finds them in DT?), or what kind of service shortcut from my side should accidentally move the Peakto error logs to DT?

So, I see the “service shortcut interference” as a hypothetical. But then it nowhere seems to match a plausible scenario as to how this interference should work… I am not a systems or coder guy. But I do not see any plausible explanation. Yet.

Also, I do not yet understand how to read/interpret the error logs of DT Inbox, which seem to expect the Peakto files there, but at the same time do not find any trace of them in a DT internal search… :thinking:

How are you using this Peakto app in conjunction with DEVONthink?
It appears to be writing log files into the internals of the Global Inbox. Did you open a file in the Inbox with Peakto?

Thx, Bluefrog – I think this might be another worthwhile alley/scenario.

The way both apps intersect in use is – afaiaa – only due to the same folders being indexed by both apps. that is the original photo folders, but not the log / application support folders.

Do you think this could cause the apps to be irritated? :thinking:
– On the other hand: the DT-indexing of the photo folders happens in another, dedicated DB, not via Inbox. So, it would still be surprising to see the logs end up in the Inbox, I guess…

PS – As I am in parallel trying to make Cyme/Peakto aware about the issue, I will also forward them this line of thinking… And see what they can say about it, knowing the way they index etc.

By now I also encountered the same issue from within HoudahSpot, trying to open parent folder of some file through it. So, it´s not specific to Peakto.

now, spending 1/2 day on it, I am further into the issue – but still can´t solve (or even identify) the root cause of this.

after using an alternative Finder app (QSpace), I could see the standard app associated with folders, the one opening opening folders by “default” as shown by the context menu.
I couldn´t see this in the finder, as it doesn´t have an “Open with…” context menu.
Indeed this lists DEVONthink as standard app associated. Here I am not sure this is related to OS “services” or in what way.

Still, when opening folders in Finder, or even in QSpace, the folders open the way they should.
When using external apps – like Peakto or HoudahSpot – they seem to take a different mechanism. And this starts an import to DT4.

I am not sure this is associated to the position of DT4 as standard app in the “Open with…” context menu (– nor how this got there). But I suppose there is a link, or at least this is an index of the same problem.

From a hint at SuperUser, I also tried to reset the Finders standard associations with files and folders (multiple times). I used:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -kill -r -domain local -domain system -domain user

But even after that and restart, I still experience the same problem pattern: whenever opening a folder via an external, non-Finder app auto-import into DT4 is triggered.

Also, I never experienced that issue before I had DEVONthink 4 installed.
Doesn´t mean this is proof of anything. But currently I have to work through the evidence as ‘normal user’…

So, this leads me to 3 questions:

  1. anyone an idea / hint what could be the underlying problem?
  2. can it be ruled out with total reliability that this is not a (system-)bug caused by DT4?
  3. does anyone know how to reset the folder-app association for whatever is shown in the contextual menu “Open with…” as regards systems folders?

TIA!

Well, considering you are the only person to report this issue…

I am still baffled by the fact that this started only recently, w/ installation of DT4 being the last big ‘event’ on my system. It didn´t happen when DT3 was still installed, and that remains a little irritant. especially as there was no subsequent modification of any services from my side (in fact, I wouldn´t even know how to change folder affiliation :grin:).

In that respect, anyone who can tell me this doesn´t happen for him/her when opening folders outside of Finder (or Finder replacements) and DT4, would be a consolation. as it would probably be a kind of (soft) ‘falsification’ of the possibility, this is caused by the beta. (I am sure there are other people here, with HoudahSpot installed, so maybe anyone could just try this simple step, and open a folder from within that.).
– Anything helpful is appreciated as to this + (ruling out) explanations. :folded_hands:

Regardless of the explanation side, I also appreciate anyone with knowledge how to get to the service level association of (systems) folders and troubleshoot that.
– as I neither know how to a) get there in principle, nor b) how to change/modify/rectify this wrong and troublemaking binding for folders.
(– as I said, resetting the systems associations of file + folder handling w/ above quoted code, didn´t do anything in this respect.)

All constructive help appreciated. TIA.

I’ve already opened folders found with HoudahSpot and it opened in a Finder window, as it normally would on a Mac.

Thx for that, @BLUEFROG.

If anyone here with deeper knowledge about the MacOS can share hints as to how to get rid of this unwanted (“secondary”) binding of folders to DT, I´d really appreciate help on this. :folded_hands:

For me it (also) works perfectly and as expected: the folder opens in Finder.

Stephen

Thx, @Stephen_C for confirming!
So, the riddle remains confined to my computer :grinning_face_with_smiling_eyes:. Good, in a way :relieved_face:

So, leaves me hoping for a wizard to come and borrow me a wand to un-coax the folders from their unhappy & mysterious link to DT… :magic_wand:

It sounds like you’d be better off opening a support ticket with your logs. Looks like there’s an issue with a setting somewhere on your device.

For what it’s worth though, the ‘annoying but probably useful’ advice Apple would give you is to set up a new user profile on your Mac temporarily, and then see if the error persists for the new user. That tells you whether the error is occurring due to a profile setting or due to a system-wide issue.

Over the years they’ve regularly given this tip, but how reassuring/helpful it is tends to depend on the problem :grimacing: In your case, it might hint at whether the glitch is due to a problem with the DT4 install or whether you have setting somewhere that’s messing things up.

2 Likes

Appreciate the caretaking tip, @MsLogica !
I might be going there, though after all the diving into this, the ramaining troubles are mainly the unability to reach the Peakto logs via menu, and now an extra-click (inconvenience) w/ Houdah Spot (and maybe some other marginal app uses.).

I have several times bordered on this Apple- & user-wiping-scenario. and was always shying away from it, for fear of trading just more/new/other problems.
… and, tbh, up to now things always ironed out by way of system updates, eventually. :relieved_face:

but, I keep your advice in mind & in stock for now!

and still don’t totally give up on finding a way (recipe) to deal w/ it via terminal (or such); or even finding/ being shown a useful 3rd-party tinkering app, letting me get to the esoteric folder-app binding…

anyways, thx a load! it’s noted!