repair broken Finder aliases

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

“HD:Users:me:Work:company:to read:8 O045 SAM Service (L)-(Mode) Guide R10 ISSUE1.00.docx”

“HD:Users:me:Work:company:to read:4 035 LAS L2+ Service(Mode) R0 ISSUE2.00 (s+n).ppt”

These are company files, so I obfuscated the filenames but leaving spacing and special characters.

It could be it’s MS warez. I tried adding the enclosing folder to Spotlight Preferences’ Privacy list, then deleting it from there and Console immediately logged

Can anyone try with some doc or ppt files?

@ msh

Thank you.
I see no special character in the file names so I’m always puzzled.

I assume that you have more than one docx file and more than one ppt one so although I dislike Merdosoft I don’t think that there may be a link between this company and the problem.

Yvan KOENIG running Sierra 10.12.6 in French (VALLAURIS, France) jeudi 3 aout 2017 17:39:13

There seems to be a problem with the mdimporter and those files.

Fwiw, I rebuilt the metadata stores with mdutil -E / and still get those same false positives. Oh well…

All Finder scripts for removing dead Finder file aliases that I have found on the net and in AppleScript books contain one major error: they do not take into account that the Trash folder may be contained within a folder of the user’s choice. For example, inside the user’s home folder … And an attempt to delete an already deleted (trashed) Finder file alias results in a script error.

Second: logically, the search should be recursive.

To permanently get rid of hundreds of “dead” file aliases (usually created by OS and applications), I wrote the following Finder script. Here it is:


set cleaned_Aliases to 0
set cleaned_alias_files_list to {}
set theFolder to choose folder default location (path to home folder)
set theTrash to (path to trash) as text

tell application "Finder"
	
	set theTrash to folder theTrash
	with timeout of 1800 seconds -- takes a while for big folders like home folder
		set alias_List to every alias file of entire contents of theFolder
	end timeout
	if alias_List is {} then return
	
	repeat with i from 1 to count alias_List
		set the_alias_file_ref to item i of alias_List
		-- avoid situation when attempt to delete from the Trash 
		if not (container of the_alias_file_ref) is theTrash then
			-- check if exists original item for current Finder alias
			if not (exists original item of the_alias_file_ref) then
				try
					set theAliasAsText to the_alias_file_ref as text
					move the_alias_file_ref to trash
					set cleaned_Aliases to cleaned_Aliases + 1
					set end of cleaned_alias_files_list to theAliasAsText
				end try
			end if
		end if
	end repeat
	
end tell

return {cleaned_Aliases, cleaned_alias_files_list}

– Result – > 702 !!! dead aliases was found and deleted in my home directory