Folder expanded twice in path

Scripting Forums AppleScript | Mac OS X
#1

I have a script for handling tracks/files in iTunes. Generally it seems to run as expected but there is one exceptional track which is never found. The picture below shows the effect which occurs in a simplified script…

The first open runs without any trouble. But the second one (on a file structure which is basically the same - the accessed files + folders do exist in both cases) brings the Execution Error. As you can see in the message, for reasons which are inexplicable to me, folder “Compilations” appears twice in the path - so obviously the file isn’t found.

My only suspicion was that the ( in the folder name was somehow upsetting the system but I have tried removing it (or balancing it) and the same error still comes with just this track.

If anyone can explain that or suggest a solution to the problem, I would be grateful! The lights are going out for me :frowning:

Model: iMac
AppleScript: 2.1.2
Browser: Firefox 12.0
Operating System: Mac OS X (10.6)

#2

Hi,

first of all, HFS paths start directly with the disk name, not with a colon.
In the second line the last path component may contain illegal (not path compatible) characters

#3

Thanks, Stefan.

Though properly there maybe shouldn’t be a colon at the start of the HFS path, both with or without seems to be accepted (see examples below - “Music” is actually a folder although I refer to it as disk in my scripts). I had also tried with Volumes:Music:… but without success.


tell application "Finder"
	(* All these versions compile and run *)
	open file "1-09 Arnold_ Main Titles.m4a" of folder ":Music:iTunes:iTunes Music:Compilations:The Belles of St. Trinian's:"
	open file "1-09 Arnold_ Main Titles.m4a" of folder "Music:iTunes:iTunes Music:Compilations:The Belles of St. Trinian's:"
	open file "1-09 Arnold_ Main Titles.m4a" of folder "The Belles of St. Trinian's" of folder ¬
		"Compilations" of folder "iTunes Music" of folder "iTunes" of disk "Music"
	
	open file "09 Golijov_ 02. Tenebrae II.m4a" of folder ¬
		"Tenebrae - for string quartet (2002, re" of folder "Compilations" of folder "iTunes Music" of folder "iTunes" of disk "Music"
	(* When the statement above was executed successfully, the folder was found in its truncated form
			and then reorganised -by iTunes, I suspect? It was renamed with the full untruncated form but
			with a null character before the T of folder Tenebrae *)
	
	(* This version brought the Execution Error with folder "Compilations" listed twice *)
	open file "09 Golijov_ 02. Tenebrae II.m4a" of folder ¬
		":Music:iTunes:iTunes Music:Compilations:Tenebrae - for string quartet (2002, re:"
end tell

However, when today I tried the alternative form with the chain of folders written explicitly, rather to my surprise, that worked on the troublesome Golijov file. The truncated version of the album name was found and then expanded to the full, untruncated form (by iTunes, I suspect). BTW, this whole problem started when I accessed my iTunes media from iTunes on a Windows system, which modified many of the names so that I couldn’t access them properly from my Mac.

As it happens, when the untruncated form was created, it became
_Tenebrae - for string quartet (2002, rev. 2003)
with the unexpected _ at the start. Investigating this I found that it was an ASCII 0 character. Maybe it had been there all the time (as an illegal character, as you suggested) and had been the cause of my original problem (although I don’t understand why the Execution Error message shows the “Compilations” folder twice).

#4

disk is correct. HFS paths start always with a disk name (even referring to the startup volume) unlike POSIX paths which start always with a slash representing the root folder of the startup volume.

The syntax for external volumes is

HFS: “Music:path:to:folder:”
POSIX "/Volumes/Music/path/to/folder/

This explains the cause of the problems :wink:

I suspect another illegal character which is treated as path delimiter. HFS paths don’t allow colons in file names.

#5

Maybe. I had rather suspected that the (unbalanced) bracket in the truncated album name was the problem but that doesn’t seem to be the case.

For my problem in general, what I discovered was that when the Mac couldn’t find a track/file (because the name had been truncated and/or modified for Windows), if on the Mac you located the file or double-clicked on it in the Finder, iTunes would “reorganise” the file and then it would be accessible again (with the name restored to the non-truncated version). To process the >22000 tracks in my iTunes library, I tried to simulate this process in a script.

I had to learn by trial and error (and the description in the Internet of characters not allowed in Windows filenames) which characters had to be mapped (replaced by _ in the Finder names). The code I ended up with to do this mapping was


				-- Replace characters illegal in Windows file names
				set my text item delimiters to {":", ";", "/", "\"", "?", "<", ">", "|", "*", "´", "˜"}
				set the nameList to every text item of truncName
				set the artistList to every text item of truncArtist
				set the albumList to every text item of truncAlbum
				set my text item delimiters to "_"
				set truncName to the nameList as string
				set truncArtist to the artistList as string
				set truncAlbum to the albumList as string
				set my text item delimiters to ""

Eventually, after I had found out by experiment what forms of apostrophe were acceptable and what others had to be mapped to _, it seems to work. I hadn’t anticipated ASCII 0, however. Since : isn’t allowed in Windows or Mac filenames it was always mapped to _

My assumption now is that iTunes keeps the “full” version of artist, album and name, including characters unacceptable in file- or folder names, in its library whereas in the media area where the files actually exist, the mapped version of the values is used. This would allow iTunes to reconstruct (or “reorganise” as iTunes puts it) names as required.

P.S. I have now discovered that I have more tracks in my library which have albums, etc., with ASCII 0 in their names, not just at the beginning but sometimes in the middle too (e.g. character 23 in the album string in one case I looked at). Just where these ASCII 0’s came from I wouldn’t like to say.

Changing one line in the sample code given above to the following seems to let my script handle these cases too…


				set my text item delimiters to ¬
					{":", ";", "/", "\"", "?", "<", ">", "|", "*", "´", "˜", ASCII character 0}