Unexpected failure to copy files in High Sierra

Ive a couple of reports from people who say that their saved files have a length of 0
All reportees are on High Sierra.

When I save, I create a file in temporary, save it, then copy it to the chosen location.
(I did that because of apparent issues caused by Dropbox in the past)

How does your code look like? Where does it fail (1st, 2nd or 3rd step)?

The code doesn’t fail with any trapped error, and has been working without issue for many years

I create a binarystream
I get a temporary file

dim tempf as folderitem tempf = GetTemporaryFolderItem
I back that to a memoryblock TheFile =new BinaryStream(mb)

Then populate it using statements like this: Thefile.WriteInt32 version
When it is complete, I close it and set Mac items, then I save it

        tempf.MacCreator = "URSA"
        tempf.MacType = "PATT"
Thefile = tempf.CreateBinaryFile(filetypes.Myfiletype)
          Thefile.Write(mb)
          Thefile.close

Then I add a custom icon using MBS plugin

addicon tempf

Then I copy to target (f)

//move the temp to the real try f.Delete catch writelog ("can't delete original file") end try try tempf.CopyFileTo f tempf.delete catch writelog ("can't copy temp to original file") end try

Your aren’t the first with strange problems like “my code worked before but borks on High Sierra”. I’ve been bitten by this, too.

It’s unlikely that the creation of the temp folderitems fails. Otherwise the binarystream would crash.

Step 1: make sure that the temp folderitem is at the expected place by logging the NativePath.

Step 2: After writing to the BinaryStream make sure that the file has the expected size. Log this, too.

Step 3: After deleting the original file make sure that the file is really gone. Then make sure that the file has the correct length after copying. Do this again after deleting the original file. Log and log and log.

Hm… High Sierra has something called “copy on write”. I think that this is the name. What it does is that a copy is created only nominally and the real copy is created when you start writing to the file. Could this cause the problems here? That would mean that step 3 is the culprit. You could try alternative methods for step 3. Nothing comes to mind at the moment. I’m sure that MBS has methods for this.

Stupid question: I’m sure you have reasons for this complex procedure. Have you tried to overwrite the original file?

Dropbox.
The file format is legacy… (it involved some binary and some text in the same file.)

Saving part, closing, then adding new stuff would sometimes fail when Dropbox was in use because by the time the second part tried to write, the file became mysteriously read-only for a period while Dropbox got its hands on it. (I assumed)

Dropbox and the like usually mirror the documents folder, so I switched to doing everything in temp, which shouldn’t be mirrored, and should allow me to assemble the whole file in peace.
Then just copy to the target in one shot and let the Devil take it.

High Sierra has also introduced ‘Safe document saves’ without explanation. If thats the cause, it is actually doing the complete opposite.

Ah, okay. Thanks for the explanation. High Sierra sure does some very strange sugar.

Try to log every step as I outlined. Then you will see which step fails.

She is right, on High Sierra with APFS file system, duplicates are not really duplicates.