Xojo had them for the folderitem class:
MacDirID (number uniquely identifying a given folder on a given volume; you could have more than a folder with the same value only if they are on a different volume)
MacVRefNum (number identifying uniquely a given volume. Once you restart your Mac, those values may change, so you couldn’t rely on them by just storing this value in a, say, prefs file; unmounting/re-mounting a volume could also re-use previous values, I think).
I’m not current in Xojo these days; I’ve only seen they have removed/deprecated those properties. I don’t know why, but my guess is it’s not supported in the new AFPS file system (still, the were great for HFS+, which still exists).
That was one advantage I liked over other operating systems: you could move/rename folders and they would retain their internal references (unlike on Windows where the file path is the only proof of being the wanted file ) and aliases would always find the right original. Now, if this principle has actually been removed from APFS, I’m wondering how NSBookmark handles these modifications and if it’s not just a lot of steps backward (discarding a big advantage ).
Curious as what would GetSaveInto serves, in that case. If, indeed, Mac has become like Windows and Linux (the path is the only relevant information to find a file), then GetSaveInfo should be deprecated; it would just equates an ordinary path
[quote=463233:@Arnaud Nicolet]Xojo had them for the folderitem class:
MacDirID (number uniquely identifying a given folder on a given volume; you could have more than one folder with the same value only if they are on a different volume).
MacVRefNum (number identifying uniquely a given volume. Once you restart your Mac, those values may change, so you couldn’t rely on them by just storing this value in a, say, prefs file; unmounting/re-mounting a volume could also re-use previous values, I think).
I’m not current in Xojo these days; I’ve only seen they have removed/deprecated those properties. I don’t know why, but my guess is it’s not supported in the new AFPS file system (still, the were great for HFS+, which still exists).
That was one advantage I liked over other operating systems: you could move/rename folders and they would retain their internal references (unlike on Windows where the file path is the only proof of being the wanted file ) and aliases would always find the right original. Now, if this principle has actually been removed from APFS, I’m wondering how NSBookmark handles these modifications and if it’s not just a lot of steps backward (discarding a big advantage ).
Curious as what would GetSaveInto serves, in that case. If, indeed, Mac has become like Windows and Linux (the path is the only relevant information to find a file), then GetSaveInfo should be deprecated; it would just equates an ordinary path [/quote]
So, is the consensus is not to go to Xojo 2019r2 with API 2.0? Meaning, at least r1.1 still uses the old way FolderItem worked and it won’t break as much code?
Is the old way working fine in the latest OS release, under all circumstances (including on AFPS volumes)? I haven’t tried.
I think using deprecated items is a matter of taste. You can continue using things as long as they work, just be aware that Apple may just remove these APIs at times you won’t necessarily expect.
I don’t know the under-the-hood of how Xojo deals with them
I notice the documentation says not to use it for persistent access, and in that case, use a bookmark. I wonder if there’s much performance penalty for simply using a bookmark (sorry threw up in my mouth) and resolving it when you need access to the file. This way it should solve two problems. Be storable and protect against changes down the hierarchy.
All of us should go to 2019r2 as soon as possible. Or do you trust Apple to keep the old style folderitem around for much longer?
The other question is: is what you see a bug or a feature? How do other apps handle name changes in the hierarchy?
My recommendation would be to book Christian for an hour to first check if the bug is fixable or not. If it is fixable then the question becomes: how fast can Xojo fix the bug?
Then you need to decide if you want to keep your solution or if you have to bite the bullet and do a redesign of your file structure (as virtual volume for instance).
I have a related problem. The Valentina folks have updated something folderitem related for Catalina. I now got a couple of reports with “Database location is wrong” for a database that should have been created in the Documents folder.
I have always coded with this philosophy. While Apple ‘magically’ remembered where/what a file was , even if moved or renamed, to me that sounded utterly crazy.
So when I want to use a file, I construct a folderitem based on what it should be called, and where it should be.
And if it isnt there, tell the user that it is missing or moved.
In the situation above where there is a bundle, I’d get the folderitem for the parent, and then treat the children as relatives of the parent.
If the problem has arisen because of renaming while the bundle is being made,
wouldnt one solution be
-create the bundle in TEMP
-rename it
-copy whole to the final destination and filename when complete?
[quote=463340:@Jeff Tullin]I have always coded with this philosophy. While Apple ‘magically’ remembered where/what a file was , even if moved or renamed, to me that sounded utterly crazy.
[/quote]
Not crazy at all. It avoids one of the worst things about Windows, which is that “you can’t move this file, as has it open”. Once I have opened a file, why should I have to care where it is? It should be possible to transparently move it elsewhere on the same volume. Apps should be sent a file system event when this occurs, and it’s then up to them to fix up any paths they might have stored or be displaying to the user. Even MS apps seem to do this OK on the Mac.
It irritated me no end on the XP laptop I used to run Eudora on, 10 and more years ago. A mail would come in with an attachment, I’d open it, perhaps with Word, realise it was important and that I should move it immediately to the correct folder for such files before taking a closer look at it. Oh no, can’t do that: it’s open in Word. How dopey is that.
When you consider that a file is just a bunch of bytes on a disk, which I am pretty certain has a UUID. The path bullshit is simply to help a user organize their files.
When you move a file, its physical location doesnt change, same for renaming it, or replacing its contents.
What we need as developers is this file UUID; so we use that a reference (of course we need other meta data for when the file header has been removed from the table).
I dont understand whats so difficult; I suspect its done this way for Security.
[quote=463387:@Sam Rowlands]When you consider that a file is just a bunch of bytes on a disk, which I am pretty certain has a UUID. The path bullshit is simply to help a user organize their files.
When you move a file, its physical location doesnt change, same for renaming it, or replacing its contents.
What we need as developers is this file UUID; so we use that a reference (of course we need other meta data for when the file header has been removed from the table).
I dont understand whats so difficult; I suspect its done this way for Security.[/quote]
Between a physical file and Xojo’s implementation, there are the file system and the various APIs the OS provides. The new way of Xojo dealing with folderitems on Mac OS apparently uses newer APIs; I just guess those aren’t using UUID (whatever that means at a filesystem level).
The way it’s working now on macOS is how it has been always been working on Linux and Windows. I know this will be a source of debate as we can all come up with scenarios where one is more desirable than the other, but at least now we are consistent across platforms.
A good modern usage case for moveable files is something that is part of my dev cycle. My app writes log files, that I keep open in BBEdit so I can look at them. As I make changes with Xojo, I often move the user data (which includes the log files) around from folder to folder, and BBEdit effortlessly tracks the location changes. It’s also not fazed if the app’s hourly timer renames the log file and opens a new one - I just see the new one in the BBEdit window.
The macOS is not Windows and not Linux and has always, even back to pre OSX days, supported references that worked if the file was moved or renamed… it simply is EXPECTED on the Mac and RB/RS/Xojo aways supported it up until now…
What is the point of having native controls if you also can’t provide decades old expected native OS functionality on a platform?
I hadnt even gotten around to testing what would happen if the user physically renamed one of the folders inside the document bundle while the app was running I wouldnt be so upset if that didnt work. This is when they rename the document inside the app and I change the folder name via the folderitem.name property. Previously this worked fine and all the downstream folderitems I had created continued to point to the right place. They dont anymore. Changing folderitem.name breaks any folderitem references to any children that were inside that folder.
Changing the name of the folder inside the bundle isnt strictly necessary for me. I could just keep the folders named as a unique id or uuid or something. I changed to using the actual name of the document so that when I or a user did need to find something specific inside the document bundle it was easier to do so. Ive only had to do that a few times but each time it saved a lot of frustration and time to be able to find the thing by name.
[quote=463339:@Beatrix Willius]Then you need to decide if you want to keep your solution or if you have to bite the bullet and do a redesign of your file structure (as virtual volume for instance).
[/quote]
I dont have to redesign it that radically. I just have to walk through the entire object structure in my app and re-create their file references if the name of the parent object changes. Im half way through doing that now and so far its working OK.
While its incredibly frustrating to have to fix stuff that wasnt broken yesterday, my biggest frustration is that nobody said anything about this! This is a significant change in behavior from 2019r1 to 2019r2 that I dont see any mention of. It did not come up in any of the testing I had done with the betas of 2.0. Its insidious. This is going to break stuff for a lot more people than me and nobody has realized they are releasing apps with time bombs in them.
Yup I ran a bunch of tests to verify this after I made the claim above. The Mac folderitem now works the way things work on the other OS targets. I dont see any documentation there either about this though. Does it say anywhere that if you rename a folder that you have to throw away any folderitem objects that you created inside of it? This is a huge change to how the folderitem worked on the Mac.
I wouldnt be so upset if that didnt work. This is when they rename the document inside the app and I change the folder name via the folderitem.name property. Previously this worked fine and all the downstream folderitems I had created continued to point to the right place. They dont anymore. Changing folderitem.name breaks any folderitem references to any children that were inside that folder.