4 ms·
> You rarely see Unix apps re-creating files: there you instead you specify the behaviour in case the file exists with the flags of the open(2) call. I think y
by wfunction 10y ago
> You rarely see Unix apps re-creating files: there you instead you specify the behaviour in case the file exists with the flags of the open(2) call.
I think your lack of knowledge about this problem is betraying you. This is outright wrong. First, look up CreateFile() in Windows; it has flags to specify things like this as well. Second, the reason programs delete files in the first place has nothing to do with the lack of such flags. It has to do with the fact that they want to write new contents but don't want to lose data in the event of an abnormal termination. If you truncate the file that you're opening instead, then you lose that data if something goes wrong. So they create a new file and replace it with the old one when it's written.
Finally, as far as I know, 'nix tools have a tendency to outright replace files MORE than Windows tools do. That's why the underlying Windows kernel API function (NtCreateFile/ZwCreateFile) has a FILE_SUPERSEDE parameter... whose entire intention is to mimic POSIX behavior:
> The CreateDisposition value FILE_SUPERSEDE requires that the caller have DELETE access to a existing file object. If so, a successful call to ZwCreateFile with FILE_SUPERSEDE on an existing file effectively deletes that file, and then recreates it. [...] Note that this type of disposition is consistent with the POSIX style of overwriting files.
https://msdn.microsoft.com/en-us/library/windows/hardware/ff566424.aspx https://msdn.microsoft.com/en-us/library/windows/hardware/ff...
- paulddraper 10y agoExactly. Most file systems have an atomic move, that you can leverage into an "atomic write".
- vesinisa 10y agoThanks for correcting. That makes it sound almost like this could be actually fixed by swimming deep enough to the NTFS driver in Windows.
- wfunction 10y agoThere is such a thing as NTFS tunneling, if that's what you mean. Not sure what you have in mind if you mean otherwise.
- asveikau 10y agoNTFS tunneling is a hilarious feature. To those who are not well versed in this: This was a hack for 2 things that exist in the universe: 1. Apps that save their documents by "delete document, re-create document by the same name". 2. The fact that said apps (especially when you consider that they might be written for Win3.1 or DOS) could be accessing the documents by 8.3 names (eg. MICROS~1.TXT) What ntfs.sys will do is: for some period of time after deleting a file, remember the "long filename" of a corresponding short name, and re-hydrate it when you re-create. So when you delete MICROS~1.TXT and create a new MICROS~1.TXT, ntfs.sys will remember that this file is also called "Microsoft.txt" and re-create that name.
- asveikau 10y agoI would go so far to say (though I've met few people who grok this, as Windows filesystems is pretty rare as a specialty these days) that delete-and-recreate is a huge antipattern and recipe for failure on Windows. The reason: Delete behavior. In NT, when you delete a file and handles are open, the name sticks around until all handles are closed. Any attempt to re-open (including re-create) with the same name will fail with STATUS_DELETE_PENDING while this is the case. Combine that with the fact that most operations in NT (including delete or rename) happen via opening handles to the file first and you have lots of chaos and race conditions. So the delete + recreate pattern is very likely to bite you later as a "re-create fails randomly".
- wfunction 10y agoWhat's your alternate recipe for success?
- asveikau 10y agoI don't think I have one unfortunately. It depends greatly on the scenario. Usually I'd say come up with a unique name if you can. Otherwise I'd say try to overwrite (possibly overwrite via rename, rather than CreateFile, to avoid the data loss you mention). I've even written some code to rename to a unique name first, then delete.
- wfunction 10y agoOK, so let me explain why your reasoning is wrong. The problems here only occur if your app is modifying files that do not "belong" to it. For apps that store config files, databases, etc., these problems should not arise, because those files should only be touched by those apps, and (a) the app is already aware what metadata the file should have and is the one maintaining control over the files, and (b) the app can make sure that it is never using a file that it is trying to delete. If the user is messing with the app's files, then the user is just as responsible for not preventing their deletion as he/she is responsible for not corrupting their contents. You can't blame the deletion behavior for that; the responsibility for proper care rests entirely on the user, and having a different delete behavior doesn't fix the core problem. For files that don't belong to the app, the situation is entirely different. First, apps should not be deleting files that don't belong to them without user consent. And if the user is consenting, the user is responsible for ensuring this does not cause problems. Second, those that modify files they do not own are responsible for all aspects of this, including preserving metadata. This is of course difficult and quite a burden, but at this point, it is considered a bug in the application if it does not do this correctly. Again, the app is the one mucking with files that it does not own, so the app and the user together are responsible for maintaining consistency, not the OS.