There’s a difference when a file is overwritten (replaced) between Xojo-made apps and other apps (e.g. the ones from Apple). I’m talking about plain Xojo methods, here, not plugins.
This difference can be seen that way, for example (once with, say, TextEdit and once with a Xojo app):
• Choose an existing file in the Finder, belonging to the target app.
• Add a tag to the file; then open the file using its app.
• Save the file (modify it if necessary).
• Look in the Finder: the TextEdit file has kept its tag while the Xojo one has lost it.
I’m guessing this difference is because Apple’s apps save to a temporary file and then use the ExchangeFiles API, while Xojo just replaces the existing files (untested theory, but seems reasonable).
Is it not “unsafe” that Xojo doesn’t use (or provide) a ExchangeFiles call by default? I mean, any Xojo app not using ExchangeFiles for saving documents make the user losing the tags (and probably other metadata) (s)he had set. That’s “destructive”.
The ExchangeFiles method couldn’t replace plain writing to a file, obviously (as it needs another file), but without it, we have to overwrite tags or use plugins to achieve a simple task .
Yes, I was referring to methods to save documents to files. I rarely use TextOutputStreams, so I’m not sure whether that applies to them as well, but I guess so.
Yes, I know it’s logical. My point is you don’t lose tags (Finder label) when you save with most apps. The default behaviour in Xojo (that is, without using plugins) removes them and that’s unwanted for most of the times a user saves.
I think it’s on you to avoid erasing and recreating. I don’t know what you’re doing, but if you are creating a new file, and wanting to save such content over an existing one preserving the external metadata associated to it, a way could be doing a BinaryStream overwrite changing its contents to the new contents and keeping the metadata, another not easy way is to learn how to migrate that metadata to the new file, delete the previous one, and rename the old one as the intended old name. One seems easy, the other seems less “byte writing expensive”.
Yes, it’s not a problem for me, actually (I’ll use the ExchangeFileMBS method). I’m thinking about Xojo apps in general, not necessarily made by me. The way Xojo handles files erases existing metadata (other apps don’t).
Like setting the length to 0 before writing; yes, this should work as well. But I don’t think every Xojo programmer thinks about that out of the box, so the removal of metadata remains a problem.
I’m concerned about the reputation of Xojo apps (again, not necessarily mines), when the users discover their Finder labels are removed each time they save a file (e.g. in an editor), if the Xojo developper has just used a Xojo function to create a file. Sorry for not being clear.
Not really for either TextOutputStream or BinarySteam on my machine
(macOS 12.5.1 Xojo 2022r1.1)
I just tested TestOutputStream on a prefs file I have. I assigned it a tag and then overwrote it with this code:
Dim F as FolderItem = SpecialFolder.ApplicationData.Child("PLCReview.prefs")
Dim Stream As TextOutputStream = TextOutputStream.Create(f)
Stream.Write j.ToString
Stream.Close
And it did not lose the tag (BTW for this use - a pref file in application Support) tags really don’t matter.
Then I tried that on a data file using BinaryStream with the code:
Dim GzipContent As New _GzipString
Dim Stream As BinaryStream = BinaryStream.Create(f, true)
Stream.LittleEndian = True
Stream.Write GzipContent.Compress(J.ToString)
Stream.Close
I can’t say what Xojo uses under the hood, because obvious reasons.
What I can say is that almost all of my save routines use Apple’s atomic saving “wrapper” APIs. The final piece of which is [NSFileManager replaceItemAtURL:withItemAtURL:backupItemName:options:resultingItemURL:error:].
Apple’s documentation states that this function preserves the metadata of the original file, including tags and such. Apple Developer Documentation
It may be that Xojo has changed their saving routines at some point, because I know that tags were erased at some point, I also filed feedback for the save dialog including a tags field, which we had no way of getting what tags the customer added, no way of writing them to a file ourselves and Xojo didn’t handle this for us.
It may be that Apple has also changed how streams work internally and now by default they preserve meta data.
My bad…
Sorry guys, that’s just my fault. The behaviour I’m seeing occurs with a bundle that my app create (therefore, the code itself empties and deletes the folder). You’re right, creating files works as intended.
I’m really sorry for often writing my assumptions without focusing more on the issues to check whether I’m not wrong (and worse, insisting to emphasise what I think is true). I wish a moderator could remove this thread and I could stop speaking.
Well, when it makes other persons trying on their end because of a mistake, that’s still a waste of time for them that I could’ve avoided if I saw it right.
Fair enough. But this is something that regularly happens with a task as complex as programming. Helping you discover that the problem was elsewhere isn’t that different from helping you solve a problem where you expected it to be. It still helps, and the Xojo forums are filled with helpful people.
.
.