Has an Alias to a file been dropped ?

[Simon Knight]

Hi,

I am trying to discover if a Finder object dropped onto a livecode button is a "true file" i.e. a valid path and name to data or an alias. I thought I could use

Code: Select all

on dragDrop
   set the cursor to busy
   put the dragdata["Files"] into tFiles  -- also tried "text"
   put tFiles
   
   repeat for each line tFile in tFiles
      -- get the filetype of tFile  -- does not work 
      -- put it into tType
      put aliasReference (tFile) into tTheFile
      put the result into tResult
      put it into tIt
      put "Alias : " && tFile && "resolves to : " && tTheFile into field "debug"
   end repeat
   pass dragdrop
end dragDrop

However the aliasReference fails to return the true file reference as I expected. What have I misunderstood? I have written a small test stack which I hope is attached to this post and may be useful.

Thanks,

S

[stam]

I wasn't aware of this function but after reading up, i would have expected this to work:

Code: Select all

on mouseUp
    local tAlias
    answer file "select an alias"
    if the result is  "cancel" then exit mouseUp
    
    put the aliasReference of it into tAlias
    if tAlias is empty then 
        put the result
    else
        put tAlias
    end if
end mouseUp

Based on the above and the documentation, i would have expected the message box to contain the file path to the alias, but instead aliasReference of 'it' is empty and the result 'can't get alias' is put in the message box

Stepping through the code, it seems that LC immediately resolves the alias to it's referenced file.
For example if i create the alias of LiveCode 10.0.0 (dp 3) on my desktop and use the above code on the alias, "it" contains the file path to the app in the applications folder, not the alias on the desktop.
In other words it doesn't seem possible to get the reference to the alias as it immediate resolves to the file/folder it points to.

This seems like incorrect functionality? It's convenient most times, but no always perhaps? What do others think?

[Simon Knight]

#Stam, thanks for your code snip and analysis. I confirm that is what I am seeing when I run your code.

I have revisited the dropping of file alias and realise that the command aliasreference works in some circumstances. If the alias and the true file are on the same volume then it works. If however the true file is on a second volume it returns the "can't resolve file" message, whereas the answer file command does resolve aliases to true files on a second volume.

So as a minimum the dictionary entry needs updating with a clarification and I need to devise a work around for when aliases are dragged dropped.

S

P.S. I have raised a bug report #23642 as either the dictionary or the command need change.

[jacque]

Stepping through the code, it seems that LC immediately resolves the alias to it's referenced file.
For example if i create the alias of LiveCode 10.0.0 (dp 3) on my desktop and use the above code on the alias, "it" contains the file path to the app in the applications folder, not the alias on the desktop.
In other words it doesn't seem possible to get the reference to the alias as it immediate resolves to the file/folder it points to.

This seems like incorrect functionality? It's convenient most times, but no always perhaps? What do others think?

It looks like the "answer" dialog selection is converting the file to its reference as you say. If I "answer folder" and then get the files, I see the alias in the file list. That doesn't help the OP though.

So maybe the question is: why is it necessary to check for an alias when the result will always be a real file path?

[stam]

So maybe the question is: why is it necessary to check for an alias when the result will always be a real file path?

As I said - it’s convenient most times. But what do you do if you want to process aliases?

[Simon Knight]

So maybe the question is: why is it necessary to check for an alias when the result will always be a real file path?

Because of the situation when an alias is drag and dropped onto a livecode application. In my case I wish to rename the "true file" but at the moment I am unable to discover how to using Livecode Script. I suspect the fix is to use a system call to MD????? to determine if the dropped item is an alias or a file and then resolve the alias with a second call to the system.

So I've had a look and the plot thickens.... It may be a problem with Mac OS. The following Apple Script is working the same way as the Livecode command AliasReference.

Code: Select all

set af to choose file

tell application "Finder"
	set tKind to the kind of af
	if the kind of af is "alias" then
		set origFile to the POSIX path of ((original item of af) as text)
	end if
end tell

display dialog origFile

The variable tKind is only set to "Alias" when the alias object is on the same volume as the original file. When the original file is on a second mounted volume the variable tKind is set to the value of the original file. An attempt to resolve the alias with "original item of" throws an error. However, if the alias is viewed in the Finder and get info is selected "kind" is shown as an alias along with the correct value of "original". So it seems that the Finder has two methods of storing information about Finder Aliases and the Apple Script and Livecode are only able to resolve one of them.

[stam]

Apparently detecting aliases on MacOS is at best problematic...
In my mind i thought it perhaps my have been a simple issue of detecting file type/creator, but no...

see the discussion here: https://stackoverflow.com/questions/584 ... -in-mac-os

[jacque]

Because of the situation when an alias is drag and dropped onto a livecode application. In my case I wish to rename the "true file" but at the moment I am unable to discover how to using Livecode Script.

I think I'm missing something. The aliasReference always gives the true file path. Can't you rename that one? Or do you want to also rename the alias? That would be harder.

[stam]

Because of the situation when an alias is drag and dropped onto a livecode application. In my case I wish to rename the "true file" but at the moment I am unable to discover how to using Livecode Script.

I think I'm missing something. The aliasReference always gives the true file path. Can't you rename that one? Or do you want to also rename the alias? That would be harder.

when used on a file reference from drag/drop or from an 'answer file', aliasReference returns empty, not the true file path - of course, the file reference returns the actual file being referenced, not the alias... so the question is what to do if you want say to move/delete/rename the alias? There seems to be no way to actually reference this.

[jacque]

I see now. Thanks stam.

[Simon Knight]

not the true file path - of course, the file reference returns the actual file being referenced, not the alias...

Well no. It returns the actual file if the file and alias are on the same volume. When the alias is on a second mounted volume it returns the alias only with the type set to the type of the original file.

The Applescript does exactly the same as the Livecode routine so this suggests that Mac OS is having the problem.

S

[stam]

The Applescript does exactly the same as the Livecode routine so this suggests that Mac OS is having the problem.

Yep - have a look at the post from stackoverflow i linked above:

Aliases and symbolic links are fairly similar in concept, but quite a bit different in detail. The reason macOS has two different ways to do essentially the same thing is because of its history: it descends from both "classic" Mac OS (Mac OS 9 and its predecessors) and unix. The "alias" file is a descendant of the way classic Mac OS did shortcut files, and symbolic links are the way unixes do filesystem shortcuts. For compatibility (and to some extent flexibility) macOS supports both.

Well, mostly: the unix (/POSIX) APIs only recognize symlinks, and treat aliases as plain files. This is why the -L test doesn't recognize alias files.

I originally recommended recognizing alias files by their type and creator codes, but after investigating a comment from @Toby, that turned out to be much more complicated than I realized. Under recent versions of macOS, aliases of files have type "alis" and creator "MACS", but aliases of folders have type "fdrp" and aliases of apps have type "fapa". Under older versions, I found aliases of apps with type "adrp" and creator copied from the original app, and aliases of files with null type code(!). There may be other combinations, so I'm not going to recommend this anymore.

Instead, Toby's suggestion seems to work well: mdls -raw -name kMDItemContentType /path/to/file will print "com.apple.alias-file" for alias files.

mdls is the unix terminal command for looking at metadata of a file.
In this post they propose the following terminal script to discern aliases:

filePath=./aliasfile
echo "$filePath" # You should (almost) always double-quote variable references
if [ ! -e "$filePath" ]
then
echo "=> $filePath doesn't exist"

elif [ -L "$filePath" ]
then
echo "$filePath is alias (well, technically a symlink)"

elif [ -f "$filePath" ] &&
mdls -raw -name kMDItemContentType "$filePath" 2>/dev/null | grep -q '^com\.apple\.alias-file$'
then
echo "$filePath is alias (a Finder-style one)"

else
echo "$filePath is not alias"
fi

don't know if that's of any use to you, but might be the only way to do this properly on MacOS...

[Simon Knight]

don't know if that's of any use to you, but might be the only way to do this properly on MacOS...

Thanks for the link and the copy posted above. It basically confirms that the various forms of alias of MacOS are a bit of a mess. I took a look at mdls of an alias that refers to a true file on a mounted volume and as you can see there is no reference to the location of the true file. Mac OS must store it somewhere but as yet I have not discovered where and in truth I can live without being able to work with aliases. I will now go and read the details in the link:

Simons-MacBook-Pro:~ skids$ mdls /Users/skids/Pictures/SophieBoleAlias/2018-11-11-164051-1150585-Flash-Model-shoot-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2
_kMDItemDisplayNameWithExtensions = "2018-11-11-164051-1150585-Flash-Model-shoot-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2"
kMDItemAcquisitionMake = "Panasonic"
kMDItemAcquisitionModel = "DMC-G80"
kMDItemBitsPerSample = 48
kMDItemColorSpace = "RGB"
kMDItemContentCreationDate = 2018-11-11 16:40:51 +0000
kMDItemContentCreationDate_Ranking = 2018-11-11 00:00:00 +0000
kMDItemContentModificationDate = 2018-11-11 16:40:51 +0000
kMDItemContentModificationDate_Ranking = 2018-11-11 00:00:00 +0000
kMDItemContentType = "com.panasonic.rw2-raw-image"
kMDItemContentTypeTree = (
"com.panasonic.rw2-raw-image",
"public.camera-raw-image",
"public.image",
"public.data",
"public.item",
"public.content"
)
kMDItemCreator = "Ver.1.3 "
kMDItemDateAdded = 2021-01-28 23:13:00 +0000
kMDItemDateAdded_Ranking = 2021-01-28 00:00:00 +0000
kMDItemDisplayName = "2018-11-11-164051-1150585-Flash-Model-shoot-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2"
kMDItemDocumentIdentifier = 0
kMDItemEXIFVersion = "2.3"
kMDItemExposureMode = 0
kMDItemExposureProgram = 3
kMDItemExposureTimeSeconds = 0.02
kMDItemFlashOnOff = 1
kMDItemFNumber = 3.2
kMDItemFocalLength = 25
kMDItemFocalLength35mm = 50
kMDItemFSContentChangeDate = 2018-11-11 16:40:50 +0000
kMDItemFSCreationDate = 2018-11-11 16:40:50 +0000
kMDItemFSCreatorCode = ""
kMDItemFSFinderFlags = 0
kMDItemFSHasCustomIcon = (null)
kMDItemFSInvisible = 0
kMDItemFSIsExtensionHidden = 0
kMDItemFSIsStationery = (null)
kMDItemFSLabel = 0
kMDItemFSName = "2018-11-11-164051-1150585-Flash-Model-shoot-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2"
kMDItemFSNodeCount = (null)
kMDItemFSOwnerGroupID = 99
kMDItemFSOwnerUserID = 99
kMDItemFSSize = 19789312
kMDItemFSTypeCode = ""
kMDItemHasAlphaChannel = 0
kMDItemInterestingDate_Ranking = 2021-10-26 00:00:00 +0000
kMDItemISOSpeed = 800
kMDItemKind = "Affinity Openable"
kMDItemLastUsedDate = 2021-10-26 14:05:38 +0000
kMDItemLastUsedDate_Ranking = 2021-10-26 00:00:00 +0000
kMDItemLensModel = "LUMIX G VARIO 12-35/F2.8 "
kMDItemLogicalSize = 19789312
kMDItemMeteringMode = 2
kMDItemOrientation = 1
kMDItemPhysicalSize = 19791872
kMDItemPixelCount = 15833216
kMDItemPixelHeight = 4592
kMDItemPixelWidth = 3448
kMDItemProfileName = "Display P3"
kMDItemRedEyeOnOff = 0
kMDItemUseCount = 3
kMDItemUsedDates = (
"2021-10-25 23:00:00 +0000"
)
kMDItemWhiteBalance = 0

[Simon Knight]

So the following terminal command returns the true path

ls -l

and when run on one of the aliases it returns :

skids$ ls -l /Users/skids/Pictures/SophieBoleAlias/2018-11-11-164135-1150589-Flash-Model-shoot-MonoChrome-Selected-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2
lrwxr-xr-x 1 skids staff 175 24 Mar 09:43 /Users/skids/Pictures/SophieBoleAlias/2018-11-11-164135-1150589-Flash-Model-shoot-MonoChrome-Selected-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2 -> /Volumes/Image_Library_SSD/Photo-Library/2018/2018-11-11/2018-11-11-164135-1150589-Flash-Model-shoot-MonoChrome-Selected-Sophie-Bole-portrait-Night-Club-NightClub-Lincoln-.RW2
Simons-MacBook-Pro:~ skids$

Now all I need to discover is how to determine the type of file dropped : true file; local alias; remote alias.

[stam]

As far as i can tell, the best way to detect if a file is an alias on MacOS using the terminal is:

Code: Select all

mdls -raw -name kMDItemContentType <filename>

In my initial example, creating an alias of LC 10 DP3 on the desktop, typing the following in the terminal

Code: Select all

mdls -raw -name kMDItemContentType "/Users/stam/Desktop/LiveCode 10.0.0 (dp 3)" 

returns

Code: Select all

com.apple.alias-file%  

Hope that helps,
Stam