FWIW: It seems Pan X has recently changed its behavior regarding paths. It happens in Pan X only, not in Pan 6; so this has nothing to do with my system upgrade to High Sierra:
Some of my databases – migrated from Pan 6 – contain import procedures with detailed paths containing colons eg. “MBP:Users:MyName:Desktop:Filename.txt”. Now, this kind of paths doesn’t seem to work anymore. Panorama X gives me errors “The File … could not be found.”
This happens since a few days, maybe since version 0.9.006.
When I drop the file into a procedure window in Pan X, I get the path with slashes, and this path syntax works.
The same paths (containing colons) continue to work in Pan 6.
Paths with colons work fine for me, but I am still using Sierra, not High Sierra.
If this doesn’t work, it’s entirely possible that this is due to some change in High Sierra. The fact that it continues to work in Panorama 6 means nothing. Panorama 6 continues to use the old Carbon API’s, which only support the colon format and know nothing about the UNIX format with slashes.
Panorama X has special support for the colon format. If it detects colons in the path, it internally converts them to the / format, which is the only format used by Cocoa. In other words, only Panorama understands paths with colons, other Cocoa programs do not. This internal conversion isn’t just a straight replace, there is special handling for the volume name. This code in Panorama X is several years old, and hasn’t been changed since May 2013 – over 4 years ago. In other words, this code definitely did not change in any recent Panorama X release.
It’s possible that High Sierra has changed something in one of the APIs getting called by this internal conversion routine. Perhaps this has something to do with the conversion to APFS – is your drive a SSD that converted to APFS? I reviewed Apple’s 10.13 developer notes and don’t see any documented change that should affect this, but it could simply be an Apple bug – after all, we are talking about an entirely new filesystem here.
Does the info(“volumes”) function work for you? This uses some of the same code used for converting from the colon to / format.
Do you have more than one drive on your computer? If so, it would be interesting to know if perhaps paths on an external drive work – that is a slightly different code path internally.
If anyone else is using High Sierra and paths with colons it would be interesting to know if they work.
No, info(“volumes”) gives me an unexpected result:
I have no disk named “Hazel”, but I am using an utility “Hazel”; I do not know why Hazel is displayed here as a volume name.
I then attached an external HFS+ disk with two volumes, and info(“volumes”) displayed the external volume names correctly, but the internal again with the wrong name “Hazel”:
I don’t have Hazel, but I am familiar with it. Could you have a disk image for the Hazel installer mounted? Yes, I’m sure that is it – I just downloaded Hazel and when I mounted the disk image for the installer – voila! I had a disk named Hazel. So I think that solves that mystery.
I’ll bet if you try a path on your Intenso 1 or Intenso 2 drive it will work even if you use colons. But since Panorama apparently can’t detect the name of the main drive, it is not going to be able to convert the colon paths.
I am suspecting that this is an Apple bug and I won’t be able do anything about it except report it and hope that they fix it sooner rather than later.
This works on a Mac with the new file system and 10.13.3 installed:
filesave “/Users/tcooper/Desktop/lvstuff.txt”,“ABCDEFG”
displaydata fileload(“Macintosh HD:Users:tcooper:Desktop:lvstuff.txt”)
But this, without the volume name, does not:
doesn’t work because it is not valid. It would not work in Panorama 6 either. When using the format that uses colons, you MUST include the volume name, like this:
"Macintosh HD:Users:tcooper:Desktop:lvstuff.txt"
There is one exception – the first path would work IF used from a database that was saved in the Users folder, in which case this would be a relative path, not an absolute path. By “in the users folder” I mean directly in that folder itself, not in a subfolder.
There was an extensive discussion of the old and new path formats in one of the videos.
I was just responding to the above statement “If anyone else is using High Sierra and paths with colons it would be interesting to know if they work.” So I tried some paths and found that colons are still okay and the testing confirmed what Jim said, paths with colons need to have the volume included.
Dave, I’m very reluctant to disagree with you, when I do I am almost always wrong. However, I am going to go ahead and slightly disagree with you in this case. If the first element of a path with colons is a valid volume name, then the path is an absolute path. If it is NOT the name of a volume on this machine, it is treated as a relative path.
I just did a test to verify this. Actually, my explanation wasn’t quite correct. The path
"Users:tcooper:Desktop:lvstuff.txt"
is a valid relative path, but would only work if the current database was stored at the root level of the hard drive, in other words if the database was “side by side” with the Users folder (which usually isn’t allowed unless you have changed permissions).
If the database was stored in the Users folder as I described before, then the relative path would be
"tcooper:Desktop:lvstuff.txt"
Dave is correct, however, that it will also work if a colon is put in front, like this:
":tcooper:Desktop:lvstuff.txt"
Of course probably none of you have databases stored in the Users folder or the root folder, but the point is that relative paths do not have to start with a colon.
I did test this, not with the Users folder, but with 3 folders named Test1, Test2, and Test3. Test3 was the innermost folder and contained the text file. Test1 was the outermost and contained the database. I thought I tried all the possibilities, but I apparently missed the one that began the path with Test2, without the leading colon.
BTW. In Panorama 6 displaydata fileload(folder(":Test2:Test3:"),"Testing.txt") works, but
I just tried a test, where I changed the name of Test2 to the name of my flash drive. In that case, it appears that Panorama X gives precedence to the folder, over the volume. If it were a hard and fast rule, that colon separated paths begin with a colon, when they are relative paths, there wouldn’t be any opportunity for this kind of name conflict.
This wasn’t intentional, and looking at the source code, I don’t understand why it would do that.
In any case, paths with colons are supported to allow for compatibility with databases written with Panorama 6. For new applications, I would recommend using unix paths with the / character, in which case there is no ambiguity.
