File vs Alias - Advantages and disadvantages ?

Hi. An alias checks itself for existence; e.g.:

set myPath to "MacBook HD:Users:ldicroce:Desktop:Mol Cell_Best.pdf"
alias myPath --fails or doesn't

Another advantage is that an alias has a memory, in that it can be tracked after moving, however, some apps specifically want to receive a string, alias, file, or—rarely—a POSIX file, as evidenced by their dictionary requirements.

Thanks, Marc.
Those are good points.

Are you not now referring to a Finder alias? Not the same thing, IMHO.
A Finder alias is a file, an A/S alias is not. I can have

set thisAlias to alias "path:to:some:file"
-- and
set thatAlias to alias "path:to:some:Finder_alias"
-- Note: this code will not compile when those files do not exist

Yes, a Finder alias “knows” where its original is, even when the original is moved.
An A/S alias cannot do that - if you move the file that it points to the connection is lost.
Unless, of course, you point it to a Finder alias. But you cannot move the alias file, only the original, for the connection to remain intact.

From the AppleScript Language Guide:

Later on there’s an example of an alias in code, and it says:

However…

I wonder if that has changed recently. I’m pretty sure that something like this:

set docsFolder to path to documents folder
set thePath to (path to desktop as text) & "Test.app"
set theAlias to alias thePath
tell application "Finder"
	move file thePath to docsFolder
end tell
display dialog (theAlias as text)

Used to display the HFS path of the moved file. But when I run it here under Mojave, it actually displays the POSIX path of the original location of the file. Coercion of an alias to text should always return an HFS path.

So I’m wondering if resolving of modified aliases has been broken in recent versions of the OS. If so, it’s not totally surprising. AppleScript aliases used the same resolving mechanism as alias files used to, but alias files now new use a completely different mechanism (bookmarks). There’s no sign that AppleScript has been similarly updated. (I guess it could also be related to APFS rather than the OS version, too.)

I did check before I posted, and here A/S aliases don’t follow a moved file. I’m running 10.11.

All aliases are file pointers, but not all aliases are files in the alias class; i.e. Finder aliases.
This works as expected under Sierra. I can’t speak to later versions’ behaviour.


tell application "Finder" to make file with properties {name:"test File"} 
set targ to alias ((path to desktop as text) & "test File") --not a Finder alias
tell application "Finder" to move targ to trash
log targ --note that this resolves to the same file, but HFS path is updated
tell application "Finder" to move targ to (make folder)

It doesnt work in Mojave.
When I do “log targ”, I get:
(alias /Users/ldicroce/Desktop/test File)
It is not updated.

And when I do “tell application “Finder” to move targ to (make folder)”, I get:
Finder got an error: File some object wasn’t found

The script behaves flawlessly under High Sierra.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) samedi 23 mars 2019 19:38:39

I’m running Mojave and I get the same exact result as Idicroce. This is an interesting thread.

The reason they were called aliases is precisely because they behaved the same as file aliases, and the underlying code was the same.

Sorry, but that’s just not true.

Again, this is just not so.

And fails here under Mojave. From the log:

tell application "Finder"
	make new folder
		--> folder "untitled folder 3" of folder "Desktop" of folder "shane" of folder "Users" of startup disk
	move alias "/Users/shane/Desktop/test File" to folder "untitled folder 3" of folder "Desktop" of folder "shane" of folder "Users" of startup disk
		--> error number -43
Result:
error "Finder got an error: File some object wasn’t found." number -43

@ Shane STANLEY

I wish to know exactly the step, which introduce a new behavior.
Here these instructions :

tell application "Finder"
	set targ to make file with properties {name:"test File"}
	log "point 1"
	set targ1 to targ as alias
	log "point 2"
end tell
set targ2 to targ as alias

issue the log:

tell application “Finder”
make with properties {name:“test File”} new file
→ document file “test File” of folder “Desktop” of folder “" of folder “Users” of startup disk
(point 1)
get document file “test File” of folder “Desktop” of folder "
” of folder “Users” of startup disk
→ alias “SSD 500:Users::desktop:test File"
(point 2)
get document file “test File” of folder “Desktop” of folder "
” of folder “Users” of startup disk
→ alias “SSD 500:Users:**********:desktop:test File”
end tell

If I understand well, on your side, one of these steps return a POSIX path (or a POSIX file).

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) dimanche 24 mars 2019 11:55:13

It happens after the file has been moved.

Thanks Shane.
So, if I understand well, the instruction move targ to trash doesn’t change the contents of targ.
What if you code :

tell application "Finder"
	make file with properties {name:"test File"}
	--> document file "test File" of folder "Desktop" of folder "**********" of folder "Users" of startup disk
	--> are you getting that or "/Users/shane/test File"
	set targ1 to result as alias
	--> alias "SSD 500:Users:**********:Desktop:test File"
end tell
set targ to alias ((path to desktop as text) & "test File")
--> alias "SSD 500:Users:**********:Desktop:test File"
tell application "Finder"
	set targ2 to (move targ to trash)
	-->  document file "test File" of folder ".Trash" of folder "**********" of folder "Users" of startup disk
	--> if I understand well here you would get : "/Users/shane/.Trash/test File"
	if (class of targ2) is text then set targ2 to POSIX file targ2
end tell
tell application "Finder" to move targ2 to (make folder)

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) dimanche 24 mars 2019 19:13:45

No, that works fine. It’s not any command that causes the issue – it’s simply the fact that the file is not where it originally was. Aliases are meant to track their files, but it looks like under Mojave – or perhaps under APFS – they no longer do.

I run OS X Captain, so I can’t check if the following alias tracking example works under Mojave:



property the_alias : missing value
property last_pathname : ""

if the_alias is missing value then
	set the_alias to choose file
else
	set this_pathname to the_alias as string
	if this_pathname = last_pathname then
		display dialog "The file hasn't moved"
	else
		display dialog "Old file path:" & return & ¬
			last_pathname & return & ¬
			"New location: " & return & ¬
			this_pathname
	end if
end if

set last_pathname to the_alias as string

This is an example from one famous book. It was tracked the alias between runs of the script, even when the source file was moved or renamed, unless script was recompiled.

It would be interesting to know if it still works.

So I did a simple test again, this time on an external HFS+ disk:

set theAlias to alias "Untitled:Test.rtf"
tell application "Finder"
	move file "Untitled:Test.rtf" to folder "Untitled:untitled folder"
end tell
theAlias as text
--> "Untitled:untitled folder:Test.rtf"

This time it worked as documented. This rather confirms my suspicion that it’s an APFS issue rather than OS-version related. Which makes sense: APFS doesn’t support the underlying file ids used by the alias manager, and as the alias manager has been deprecated since macOS 10.8, it was never likely to be updated.

@ Shane
Hey,
what does this mean in practical terms for us?
What should we use and what should we not use to be sure that our scripts will work in the future?
Should we avoid to use AS alias? Is that what you are suggesting ?
Thanks!

In practical terms, all it means is that you can’t rely on using properties to hold aliases in the expectation they’ll resolve even if the files they refer to are moved. I don’t think anything other than a small proportion of scripts ever did rely on this – perhaps more did in the days pre-OS X, when where to store files was a more free-wheeling affair. But the lack of screaming suggests it’s more one of those things that sounded good but wasn’t often rally needed.

If you need this feature now, you can always use my PrefsStorageLib.

Thanks !