New Finder Bug alias "/Users/didoda/Desktop/XXX" (at least in Mojave and Monterey)

Scripting Forums AppleScript | Mac OS X
#1

To add to the list of very annoying Finder bugs, here is a new one - to me at least:

set aFile to choose file default location path to desktop folder
tell application "Finder"
	set name of aFile to "XXX"
    log aFile
	update aFile
end tell

This is the Finder’s reply:

set name of alias "Mojave:Users:didoda:Desktop:yyy" to "XXX"
--> "XXX"
update alias "/Users/didoda/Desktop/yyy"
Error: File not found (fnfErr:-43)

My point is not (so much) that since the file is referenced as an alias, the Finder should be aware of its own previous name change (which sometimes it does, sometimes not), but that it converts the colon separated HFS path to a slash separated posix path for use in an alias reference!? (I use update here only since it seemed to give consistent results, at least after the file rename, some other commands show this bug inconsistently, e. g. the Finder’s move, copy or choose file)

On top of it, at least on my system, this

use AppleScript version "2.4" -- Yosemite (10.10) or later
use framework "Foundation"
use scripting additions

alias "Mojave:Users:didoda:Desktop:XXX"
alias "/Users/didoda/Desktop/XXX"

sometimes even works, but as soon as you comment out the use framework line the second alias reference causes an error. This seems all very very volatile.

Has anybody seen this?
Does anybody know a workaround? Except using ASObjC or Shane’s FileManagerLib to avoid the whole Finder mess, of course.
On a side note, I wonder why using do shell script "cp -a ...." or the like does not seem to be popular among scripters.

Thanks a lot for any input!

P.S. Just checked: this bug can be observed in both SD 8.0.6 and Script Editor.

tell application "Script Editor"
	choose file default location alias "Mojave:Users:didado:Desktop:"
end tell
tell application "Finder"
	set name of alias "Mojave:Users:didado:Desktop:yyy" to "xxx"
	(*alias /Users/didado/Desktop/yyy*)
	update alias "/Users/didado/Desktop/yyy"
Ergebnis:
error "„Finder“ hat einen Fehler erhalten: Die Datei „some object“ wurde nicht gefunden." number -43

[Sorry for the many edits…]

#2

To reply to my own question - in part:

When a supposedly dedicated web search didn’t return anything meaningful, I more or less accidentally stumbled upon this quite old thread:

https://lists.apple.com/archives/applescript-users/2017/Nov/msg00105.html

It is worthwhile to read the complete thread. So this is another known bug, wether the Finder’s or Alias Manager’s nobody knows.

#3

This is no bug. In fact, you misunderstand how it works. The system internally updates the AppleScript Alias (deletes the old alias & creates the new), but it is not required to update your aFile variable (more properly called anAlias) in the script.

The script itself must get a reference to the new AppleScript Alias (created by the system in the background).
 

set newName to "YYY"
set anAlias to choose file default location path to desktop folder

tell application "Finder"
	set aContainer to (container of anAlias) as text
	set name of anAlias to newName
end tell

set anAlias to alias (aContainer & newName) -- OR:
-- set anAlias to (aContainer & newName) as alias

 

1 Like
#4

Interesting. My understanding was that the main purpose of an alias is to get a file reference tracked by the system, no matter where it gets moved to (on the same volume, I suppose) and / or however it gets renamed. This is why an alias reference has to point to an existing file as opposed to one that is about to be created at a certain location by the script. See here:

In this light, you may be absolutely right that it works this way, but I am afraid I find this behavior buggy.
Apart from that, Shane Stanley and others point to the fact that this is very likely an APSF issue. From my testing (only on Mojave at the moment), it is obvious that my test script works on HFS+ but not on APFS, meaning that both the alias gets updated as expected and the Finder does not try to use the odd combination of alias reference and posix path string.

So maybe it is on APFS that this behavior changed to the way you describe. Dunno.

#5

There are probably many reasons for this, but the cp utility’s requirement for a quoted POSIX path is probably a significant one. Also, getting the syntax correct can be frustrating, and, on older computers, the do shell script command imposes an overhead that people like to avoid. As regards the cp archive-mode (“-a”) option, the function of the script probably determines when and if this option is used.

There are command-line utilities that often do a better job than regular AppleScript, and the sips utility is one example. However, to copy a file, Finder or System Events just seem a simpler choice.

#6

In older systems, there was another class of alias object - the so-called System Events Alias. In addition, System Events used to work with AppleScript Aliases too (like Finder - until now).

I’ve been into AppleScript since 2019, so I can’t say how the Finder worked before with AppleScript Aliases. It’s even possible that the Finder redirected the task of resolving the AppleScript Alias to the System Events application, and it resolved the new reference according to its System Events Alias. (And you didn’t notice it). The fact is that now it works differently.

#7

Meanwhile I found the time to test this on Monterey.

The alias is not updated on APFS volumes.
It is properly updated as described in Apple’s documentation even on the cheapest HFS+ formatted USB stick.

So for me this is clearly a bug that is not even fixed in Monterey.
What you are describing is, IMHO, a (rather clumsy) workaround.

#8

Hm, yes. But it’s extremely buggy and feature limited, I am almost loosing count.
• it is impossible to move a file to a new folder under a new name in one command in the Finder or System Events as e.g. the command line mv, you have to rename then copy
• when moving files between volumes in the Finder does not move but copy, you have to delete the source file manually afterwards
• in System Events you can not move without replacing, but it seems to be broken anyway
• there is no copy command in System Events, the duplicate command seems to work only under limited circumstances
• Posix file references don’t seem to work inside Finder or System Events tell statements
• object references as well as file and folder references used in the Finder and in System Events are not mutually compatible to each other although they look perfectly identical (to me)
• in the Finder, if exists alias aFile raises an error if aFile cannot be found instead of returning false; AppleScripters seem to be used to this kind of crap, everybody else is simply dumbfounded
• the bug documented here

See here for a nice discussion of some of these aspects:

#9

pjh. I and many other forum members use Finder and System Events to copy and move files on a regular basis without issue. Some of your comments are petty, an example being the inability to move a file to a new folder under a new name in one command. Other comments reveal a lack of knowledge, an example being your complaint that POSIX file references don’t work within Finder and System Events tell statements. If you want to use the cp utility then be my guest but don’t pretend that it’s inherently better than the alternatives because it’s not.

#10

Has this kind of alias ever existed? I think never. Therefore, the error is that the Finder cannot work with such objects. It’s not related to the fact that the old alias doesn’t track filename changes.

#11

The alias has, of course, existed and the file referenced by the alias got properly renamed. So according to HFS+ standards and the documentation the existing alias (BTW, I am under the impression you are confounding alias references and alias files) should have properly reflected the new file name. It’s the main purpose of an alias. Just have a look at the docs.

The fact that on HFS+ things work as documented sufficiently prove that things got broken on APFS. I am using AS for more than 30 years, BTW. And things are getting worse and worse.

#12

So far (4 years) I have not seen a single useful use of this feature of AppleScript Alias, which you consider to be the main one, and which does not work now.

For me, this is one of the convenient ways to check the existence of a file without using tell blocks of applications. Or, one type of references to share files between applications.

2 Likes