Sorting Finder windows doesn't work anymore?

Just to give an historical reference, here, under 10.13.6 Finder behaves as described by KniazidisR.
Starting with this state:


(*
get visible of column creation date column of list view options of Finder window 1
		--> false
get visible of column name column of list view options of Finder window 1
		--> true
get visible of column modification date column of list view options of Finder window 1
		--> true
get visible of column creation date column of list view options of Finder window 1
		--> false
get visible of column size column of list view options of Finder window 1
		--> true
get visible of column kind column of list view options of Finder window 1
		--> true
get visible of column label column of list view options of Finder window 1
		--> false
get visible of column version column of list view options of Finder window 1
		--> false
get visible of column comment column of list view options of Finder window 1
		--> false
*)

If I ask Show presentation options to make the column creation date visible, the script continue to return the visible value as false (even after a close - reopen process).
If I ask the script to set the visible of the column creation date to true, the script correctly returns the value.
If I ask Show presentation options to make the column creation date hidden, the script continue to return the visible value as true (even after a close - reopen process).
It appears that the broken link between the true behavior and AppleScript is not a new feature.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) dimanche 27 octobre 2019 15:24:35

No, Yvan, I wrote a small script here to quickly experiment with different folders:


set aFolder to choose folder

tell application "Finder"
	set aWindow to container window of aFolder
	tell aWindow to tell its list view options
		set visible of its column id modification date column to true -- then, I tested here with false
		set isVisible to get visible of its column id modification date column
		set sort column to its column id modification date column
	end tell
end tell

The results were even more unexpected for me. It turns out that Finder divides folders into 3 types:

  1. Folders for which the VISIBLE property is hardcoded to TRUE. (for example, mine PICTURES folder).
  2. Folders for which the VISIBLE property is hardcoded to FALSE. (for example, mine HOME folder).
  3. Folders for which the VISIBLE property is not hardcoded and can be set to TRUE or FALSE. (for example, all folders of the root directory and the root directory itself).

This leads me to a strange thought that the behavior of the VISIBLE property is related to folders privileges…

NOTE: So far, I have only found 2 hardcoded folders on my Mac: HOME folder and PICTURES folder. Even with their subfolders, VISIBLE property works fine. You can set it to TRUE/FALSE and Finder doesn’t ignore new setting.

I apologizes but here the different kinds of windows which you described behave exactly the same way.

I tested with :

tell application "Finder" to tell Finder window 1 to tell its list view options
	repeat with colName in (get name of every column)
		set origState to get visible of column colName
		log origState
		if colName as text is "modification date column" then
			set visible of column colName to not origState
			log (get visible of column colName)
		end if
	end repeat
end tell

At first pass the log report was :

(*
tell application "Finder"
	get name of every column of list view options of Finder window 1
	get visible of column name column of list view options of Finder window 1
	(*true*)
	get visible of column modification date column of list view options of Finder window 1
	(*false*)
	set visible of column modification date column of list view options of Finder window 1 to true
	get visible of column modification date column of list view options of Finder window 1
	(*true*)
	get visible of column creation date column of list view options of Finder window 1
	(*true*)
	get visible of column size column of list view options of Finder window 1
	(*true*)
	get visible of column kind column of list view options of Finder window 1
	(*true*)
	get visible of column label column of list view options of Finder window 1
	(*false*)
	get visible of column version column of list view options of Finder window 1
	(*false*)
	get visible of column comment column of list view options of Finder window 1
	(*false*)
end tell
*)

At second pass it was :

tell application "Finder"
	get name of every column of list view options of Finder window 1
	get visible of column name column of list view options of Finder window 1
	(*true*)
	get visible of column modification date column of list view options of Finder window 1
	(*true*)
	set visible of column modification date column of list view options of Finder window 1 to false
	get visible of column modification date column of list view options of Finder window 1
	(*false*)
	get visible of column creation date column of list view options of Finder window 1
	(*true*)
	get visible of column size column of list view options of Finder window 1
	(*true*)
	get visible of column kind column of list view options of Finder window 1
	(*true*)
	get visible of column label column of list view options of Finder window 1
	(*false*)
	get visible of column version column of list view options of Finder window 1
	(*false*)
	get visible of column comment column of list view options of Finder window 1
	(*false*)
end tell

I repeat that I get this behavior under 10.13.6 (my iMac refuse more recent system).

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) dimanche 27 octobre 2019 20:51:05

I’ve been looking into this further with the thought of submitting a bug report. But it’s not at all clear how to tailor it to Apple’s bug reporting protocol, or even how many bugs are involved! I’ve also run the same tests on my El Capitan (10.11.6) machine to see if there are any differences. For anyone who’s interested, or who doesn’t mind being strangled to death by their own intestines, here’s what I’ve found:

• In both El Capitan and Mojave, scripted changes in a Finder window’s ‘list view’, ‘icon view’, or ‘column view’ options have no visible effect until the window’s either closed and reopened or its ‘target’ is switched to another folder and back. However, the new values are correctly returned to scripts.

• There are no scriptable view options for the “Cover Flow” view which exists in El Capitan or for the “Gallery View” which exists in Mojave. On both systems, though, a window can be scripted to switch instantly to the relevant view by setting its ‘current view’ to ‘flow view’. The Finder dictionaries on both systems also offer a ‘group view’. In El Capitan, this compiles as is but errors when run. In Mojave, it recompiles as ‘flow view’ and changes the view to Gallery View! This ‘group view’ setting has no connection with the Toolbar button labelled “Group By” in Mojave or “Arrange By” in El Capitan.

• On both systems, if a Finder window’s ‘sort column’ in list view is the same as its ‘arrangement’ in icon view (eg. ‘sort column’ = ‘column modification date column’ and ‘arrangement’ = ‘arranged by modification date’), changing the ‘sort column’ by script also changes the ‘arrangement’ to a matching setting. This doesn’t happen when the sort column is set manually or when the views’ sorting arrangements are different to begin with. Changing an icon view’s ‘arrangement’ by script doesn’t change the list view’s ‘sort column’. The term ‘arranged by’ in the icon view options is to do with sorting, not with what El Capitan’s Toolbar button calls “Arrange By” or Mojave’s calls “Group By”.

• On neither system does changing a list view column’s ‘visible’ setting have any effect on the number of columns visible in the window. The width of other columns may be changed in El Capitan, but in Mojave there’s no visible effect at all. In Mojave, though, each time a script sets a column’s ‘visible’ property, the number of columns subsequently returned to scripts doubles. The extra columns are all zero-width ‘name’ columns at the beginning of the returned list. The number of columns, initially 8, maxes out at 256, whereafter it becomes impossible to change any of the columns’ ‘visible’ values ever again. Attempts to change the ‘name’ column’s ‘visible’ to ‘false’ correctly raise errors, but commands setting the ‘visible’ of other columns are simply ignored. This means that if a column’s last successful ‘visible’ setting was to ‘false’, it can never again be scripted to be the sort column. This appears to be permanent for the folder to which the view belongs, but only affects Finder AppleScripting. It’s still possible to do whatever’s necessary manually in the GUI. It’s also still possible to script changes to the columns’ sort directions, even if they’re neither visible nor the sort column as far as AppleScript’s concerned. While the number of columns returned to a script can be up to 256, commands which count them directly (as opposed to counting the returned list) only see eight. Similarly, it’s not possible to use an index specifier higher than 8 to address them and ‘whose’ filters only return matches from the first eight columns.

As an experiment, I copied a “256 column” folder over my network from my Mojave machine to my El Capitan one. The El Capitan Finder also returns 256 columns from the folder window’s list view options — but there are no invisible files in the folder, so it’s not clear how this information has been conveyed. The widths of the additional ‘name’ columns are returned as 457 instead of 0. The other columns’ ‘visible’ properties can be changed in El Capitan, but the eight-column limit still applies for counts, index references, and ‘whose’ filters.

It’s time for another coffee!

I filed it under Developer Tools and only reported that changing sort columns in the Finder using AppleScript doesn’t work on Mojave and Catalina.

I included a simple AppleScript example and also mentioned that it worked a few years ago.

I think it’s all they should be concerned with!