For decades, whenever I do FolderItem.Delete (on a unlocked Visible existing file, of course), the FolderItem object stays legitimate and becomes a “promised” FolderItem. The Name still exists, it still has a Parent FolderItem - it’s just Exist=False. I then can do a BinaryStream.Create(f, true) to write the file again. This is my common method of replacing a file. (Please don’t comment on alternative ways, I know there are better ways of doing this)
I had an instance where this doesn’t happen. MacOS 10.14. Just a particular file. I do f.Delete and although the object isn’t Nil, it loses a lot of it’s properties. I can’t even do a BinaryStream(f, true) on it - I get a IOException on it.
Well if the file can’t be deleted (maybe in use?) You get an IOException… from the docs:
If the file could not be deleted, an IOException occurs. You can then check the IOException.ErrorNumber, IOException.Message or IOException.Reason to find out what went wrong (e.g. the file could still be in use, or it was locked, the directory was not empty, or the entire volume may have vanished in the mean time).
Also when you can’t write the file you get an IOException. Basicly you can ditch the .Delete (or api 2 .remove) and just use Your binaryStream.Create( file, TRUE) will do the trick without delete since the true will overwrite it.
The file is normal and is in a normal writable area. After I do FolderItem.Delete the file does disappear from a Finder window. And I’d rather not do the Create way because it doesn’t work if the data I’m replacing it with is smaller than the original file size. I should be able to delete a file, then create a new one.
Doesn’t work how do you mean, it recreates the entire file, leaving nothing behind. If you sti have data in it then that would be a serious bug.
Myabe as an alternative, delete the file the. Create a new FolderItem.temporaryfile then write to it using the binarystream, then move that file to the original location?