repair broken Finder aliases

Yvan, I was surprised because I didn’t get where those new line characters came from but now I understand.

It’s not a common problem, the problem is related to aliases you’ve created. Some of them seem to have trailing new line characters. That’s not the default behavior when creating an alias, you must have added them - maybe accidentally.

It might be more suitable to remove the affected trailing new line characters from the alias files manually.

No, I didn’t created these aliases explicitly. If I did, msh wouldn’t have the same items.

The folder Speech is not created by default but is installed by request when we need the speech tools. The folder doesn’t exist on my grand-son MacBook Pro, no more on my grand-daughter’s one.

I guess that they the entire folder is created when we ask the system to use Speech components.

I will certainly not change the names of these aliases. If they are useful, changing the names would push the applications trying to use them to crash.

Searching in Google, I retrieved a support page :https://support.apple.com/kb/PH14230?locale=en_US in which I read :
Choose Apple menu > System Preferences, click Dictation & Speech
There is no such item in 10.12.6 (or at least my old eyes don’t see it).

Amusing detail: when I retrieved the ‘annoying’ aliases with Spotlight, in the window displaying them, the ASCCI part of the names was moved vertically due to the ending return. If I copy these names and paste them as I did here, we may see that there is really an ending linebreak

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

Target Application Alias

When I navigate to open the folder containing these aliases, the names are displayed with a question mark replacing the return. I select a file name and copy it, I really get a question mark :

Target Application Alias?

Which may explain why most of us don’t take care of them (adding that normally the user’s library is hidden)

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) vendredi 28 juillet 2017 14:02:57

FWIW, on my Mac all those aliases and other files have a creation date January 18, 2014, which is back in the 10.9 time-frame. Some of the apps referred to are long gone, too.

And when I look at the code in some of the scripts – which are old resource-fork versions without extensions and thus open as untitled – they look like dinosaurs, too. I see stuff like using “set theStyledTextRecord to (theText as record)/set theText to «class ktxt» of theStyledTextRecord” before using strings in dialogs. It’s really quite nostalgic :wink:

So I do wonder if they’re doing anything more than taking up space these days…

Thank you for your feedback Shane.

According to it, I zipped all these files.
If before 2017/12/31 (guess why) no failure strike, I will remove the zipped files with the folders which contain each of them but I’m not sure if I may delete more.
At first thought, it may be done as there is no such folder on my grand-son and grand-daughter macBooks.

Courage, I will now zip the Speech folder itself :wink:

It’s probably not a problem. I wasn’t asked for a password for the zip process and for the removal of the original.

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) vendredi 28 juillet 2017 16:26:48

Mine date back to 2006. Time to make a clean install? :smiley:

You can read more about without altering line endings in TN2065.

It’s a shame that the source for AliasPath is not being shared.

Thanks.

(1) I’m aware of “without line endings” but as I rarely use shell commands, I forgot it and worse I missed it in Shane’s proposal.

(2) The source of the original AliasShare is shared.
StefanK is free to choose if he wish to share its changes or if he doesn’t.

(3) I compiled the original source with Xcode and tried to use it with :

set allAliasFiles to (do shell script "mdfind \"kMDItemKind == 'Alias'\"" without altering line endings)

set {TID, text item delimiters} to {text item delimiters, linefeed}
set allAliasFiles to text items of allAliasFiles
set text item delimiters to TID
allAliasFiles

repeat with i from 1 to count allAliasFiles
	set item i of allAliasFiles to quoted form of item i of allAliasFiles
end repeat

set {TID, text item delimiters} to {text item delimiters, linefeed}
set text item delimiters to space
set allAliasFiles to allAliasFiles as text
set text item delimiters to TID

set pathToCLI to POSIX path of ((path to desktop as text) & "aliasPath") # EDIT to fit your needs
tell application "System Events"
	set maybe to exists file pathToCLI
end tell


set brokenAliases to do shell script pathToCLI & space & allAliasFiles


# Replace the extraneous ending linefeed by the character "¶"
set brokenAliases to my remplace(brokenAliases, return & ": ", "¶: ")

# If you prefer you may replace the colon + space separator by tab character
set brokenAliases to my remplace(brokenAliases, ": ", tab)

set fileDescriptor to open for access ((path to desktop as text) & "FinderBrokenAliases?.txt") with write permission
set eof of fileDescriptor to 0
write brokenAliases to fileDescriptor
close access fileDescriptor

#=====
(*
replaces every occurences of d1 by d2 in the text t
*)
on remplace(t, d1, d2)
	local oTIDs, l
	set {oTIDs, AppleScript's text item delimiters} to {AppleScript's text item delimiters, d1}
	set l to text items of t
	set AppleScript's text item delimiters to d2
	set t to l as text
	set AppleScript's text item delimiters to oTIDs
	return t
end remplace

#=====

The process behaved flawlessly.

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) samedi 29 juillet 2017 10:45:44

I beg your pardon :confused:


@Yvan, I added a new switch -t to AliasPath.

By default (without passing the switch) the alias paths are trimmed by leading and trailing new line and white space characters.
If you pass it, the paths are printed unchanged.

New Build: AliasPath1.2

Thank you Stefan.

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) samedi 29 juillet 2017 12:23:18

Really??? It’s just funny — and a modified binary should include the license of the original.

Meanwhile my version can be treated as refactored rather than modified :wink:

It’s not a secret and it’s written in either (Objective-)C or Swift which has no purpose on MS here. StefanK just wrote a binary so you can use it. You want the code? Here is one of the thousand examples on how to resolve alias paths.

Ehm…I wanted the source to add it to MacPorts.

@StefanK, I just reran AliasPath and found two false positives, namely two aliases that are reported as broken but that actually work and whose ‘Original’ path in Get Info pane also is correct, but AliasPath gives what I think is a previous path were the target files where momentarily stored a long time ago. The only characteristics that make them stand out is their names being ~90 chars and the use of parens and plus in their names.

Does the alias file name or the original file name contain the special characters?

I tried both but can’t reproduce the issue.

Both.

Is there any way that you could be getting a path cached years ago?

I don’t think so.

AliasPath does a Spotlight search like mdfind and uses the same way to get the original path as the GitHub project.

What if you use the script posted in message #46? It use the original CLI so you will know if it report also false bad aliases.

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) mercredi 2 aout 2017 20:26:52

Your script in #46 with the binary in #13 report both aliases as broken and give also the wrong, old original path.

However

tell application "Finder"
	exists original item of alias "path/to/file"
		--> true

returns that the original path exists, as it actually is.

Maybe it’s a problem with the metadata store.

I guess the Finder performs an extra step to resolve the alias which the CLI does not. It could be quite expensive for a large amount of files.

@ msh

May you post the Hfs path of the two good aliases treated as bad ones ?

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) jeudi 3 aout 2017 10:40:14