Schrödinger's Comments

Questions & Suggestions
1

Paring this down to the simplest scenario:

On your desktop, set your Finder View options to include comments. Create a test file on your desktop and, using Get Info, give it a comment. See the comment in the desktop display? Good.

Now, create a test folder on your desktop and drag the test file into it. Still see the comment? Good.

Drag the test file back out of the folder, and use this KM Action (with, of course, appropriate directory changes) to move the file into the folder:

image
image806×120 14.7 KB

Still see the comment? I don't, either in the desktop folder display or using Get Info on the moved file. The comment is gone!

Now drag the test file back out of the folder. See the comment? I do. So the comment wasn't actually gone, it was just hiding.

It would seem therefore that KM's Move operation isn't quite equivalent to the Finder's drag/drop operation. (I'm still at KM 9.2; if this is fixed/changed in version 10, sorry to have taken your time! Oh, and I'm running Catalina 10.15.7 on a 2019 MacBook Pro.) I'm not an AppleScript guy or I'd try the same operation that way. I'd expect it works like drag/drop.

From some Googling, I know that the display of comments is tied to Spotlight indexing, and I've tried the standard way (add a folder to the Spotlight Privacy list and then delete it) to force Spotlight to re-index the test folder, the Desktop folder, and then the entire user directory, but none of those seemed to make the invisible comment show up. Even if re-indexing worked, it would still be the case that drag/drop in Finder avoids the need.

Even-money odds that I'm missing the obvious answer and will be grateful if someone tells me what it is.

1 Like
2

Finder comments are stored in a hidden file — so when you move the file you’re moving it away from its comment. When you move it back it finds it again.

2 Likes
3

Thanks, @stevelw, very helpful. So Finder comments are funky, subject to loss, and arguably poorly designed. They are useful, however, so I guess my question is for @peternlewis: Can some future version of KM preserve comments in the same way that drag/drop does, even if other file-move scenarios are subject to comment loss? (And is there a work-around in current KM?)

4

Your questions are completely fair. And you've opened my eyes to some new ideas. The website that was cited above does mention a workaround, using "xattr Comments" instead of "Finder Comments". Maybe someone could write a KM macro that modifies these comments. I like that idea, but maybe you won't. There's a macOS command called "xattr" which lets you modify these comments, which never disappear like Finder comments do. I need to start playing with this command.

Alternatives

Thankfully, macOS provides a much better way of attaching comments to a file, what it calls simply a Comment. These are displayed in the Get Info dialog in the More Info section rather than the Comments, but can’t be edited there. They’re one of the basic types of metadata supported directly by Metamer, where they appear in the Combo Box menu simply as Comment, of the type com.apple.metadata:kMDItemComment, and work fine with Spotlight. I’m not sure what’s preventing Apple from phasing out Finder or Spotlight Comments and moving to regular xattr Comments, nor why Finder Comments in .DS_Store files aren’t synced properly with their xattr. I haven’t asked Apple what’s blocking that choice, after all I’m fairly sure that the response would be “No Comment”.

Perhaps you will insist on a solution that works with Finder Comments instead of xattr comments. That's fair. Are you asking for the KM Move File action to be modified to locate and transfer that data, or for more than that? Maybe there's some public code on GitHub that Peter can incorporate into KM to make that work. I took a quick look and didn't spot anything. But I'm not very good with GitHub.

5

Thanks, @Sleepy. For me (others may have different cost/benefit ratios) I simply want to automate a process that currently includes a manual drag/drop step, and do so in such a way that the Finder comments I heavily rely on will be preserved. Having discovered that the KM Move Action doesn't preserve the comments, I simply added KM steps to copy the comment before the move and paste it back after the move. Not elegant but functional.

6

This is unlikely - if Apple’s APIs do not preserve the comments, then Keyboard Maestro wont preserve the comments itself.

You could, presumably, manually, do it yourself, reading and setting the comments as appropriate, but this is not something Keyboard Maestro will do - Apple has already made the decision as to what they want preserved in the API.

7

Thanks, @peternlewis. To be clear: Drag/drop does preserve comments in all cases that I've tested. So I take it you're saying that Apple doesn't publish the drag/drop API?

8

I'm saying Keyboard Maestro uses the NSFileManager API, and if that doesn't maintain comments, then Apple doesn’t consider that maintaining comments is the right thing to do. Basically, as far as I can tell, comments are a Finder feature, and anything except the Finder that affects files does not generally preserve comments.

9

Got it, thanks! I was failing to distinguish between macOS and the Finder. In that context, using separate KM actions to move a file on the one hand and preserve/restore comments on the other makes perfect sense, and something I can separately encapsulate in a utility Move File macro.

1 Like
10

Hey Steve,

If you use AppleScript to script the Finder to move or copy (duplicate) then Finder comments are preserved.

-Chris

1 Like
11

Thanks, Chris. Yes, as I conjectured in my original post, although now it's clear to me why. Since I have a purely KM workaround, I'll continue to leave AppleScript unexplored.

Steve

13

Please can you share this as it might be useful to others looking at this thread In the future.

14

I'll leave it to the pros (they know who they are :slightly_smiling_face:) to produce a fully-documented, error-checked, parameterized, preferred-form macro (although the pros would use a single AppleScript action), but here's the general idea for an in-line KM-only solution:

image
image806×707 83.6 KB

15

That's very cool. It should be cast in carbonite by a pro (like Han Solo was) and placed in the Macros folder. I think it should be a subroutine rather than a straight macro, because of the parameters.

16

@Sleepy But why would you carbonite a KM-only solution instead of an AppleScript version? Once it's in a separate macro/subroutine, there seems no benefit to KM-only.

17

Either KM actions or AppleScript actions can be used in a KM subroutine. Since the KM solution is already in front of us, someone could use that. I guess whichever one is faster. On the other hand, if the KM solution is just as fast, it should be preferred.

18

Sure, and I suppose the speed difference is worth testing, but note that (as Chris @ccstone says above) the AppleScript version wouldn't need the save/restore steps, since the Finder preserves comments automatically.

19

Since Chris didn't offer to write an AppleScript solution, and since you said you would leave AppleScript unexplored, then the most likely path to success here is for someone to carbonate your KM macro. I think it's an excellent macro and should be carbonited, but I don't have a stake in which way. The only way I could do it is the KM way.

20

@Sleepy :+1:

21

There are quite a few examples of moving items via AppleScript on the forum and many on the Internet.

No special coding is required to keep Finder comments, as long as it's the Finder doing the moving – System Events will fail to keep comments.

-Chris

--------------------------------------------------------
# Auth: Christopher Stone
# dCre: 2021/12/13 12:02
# dMod: 2021/12/13 12:02 
# Appl: Finder
# Task: Move Selected Items to the Given Destination Folder.
# Libs: None
# Osax: None
# Tags: @Applescript, @Script, @ASObjC, @Finder
--------------------------------------------------------
use AppleScript version "2.4" --» Yosemite or later
use framework "Foundation"
use scripting additions
--------------------------------------------------------
(*

## REQUIREMENTS ##

   • The destination folder must already exist.
      - Creating a new folder is simple but not covered by this script.

*)
--------------------------------------------------------

## USER SETTING ##

set destinationFolderPath to "~/test_directory/Destination_Directory/"

--------------------------------------------------------

set destinationFolderPath to ((current application's NSString's stringWithString:destinationFolderPath)'s stringByExpandingTildeInPath) as text
set destinationFolderAlias to alias POSIX file destinationFolderPath

tell application "Finder"
   set finderSelectionList to selection as alias list
   if length of finderSelectionList = 0 then error "No files were selected in the Finder!"
   
   move finderSelectionList to destinationFolderAlias
   
end tell

--------------------------------------------------------