3 ms·

OK, 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

OK, 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.

asveikau 10y ago
You're funny. Telling me my years of experience of this behavior biting me in the rear end is "wrong". There isn't even such thing as "my files" and not. Are you aware that many people run antivirus products that sit between you and the filesystem and might choose to also open "my" files in an asynchronous fashion based on my own actions? That such an antivirus product has been built into Windows for some time now? (msmpeng.exe) Suddenly that file you thought it safe to have exclusive access to... it wasn't. Even controlling your own actions is hard and yields unexpected results all the time. Almost any time setting dwShareMode to something other than 0x7 and I saw it bite me in some unexpected way due to things my own process is doing, that I did not think of ahead of time. Once you have Windows filesystem code doing this at any appreciable scale you will see this. It takes enough of seeing sharing violations and delete pending errors time after time to realize these are just dangerous patterns on the platform, avoid them and move on.
- wfunction 10y ago
  I didn't say your experience was "wrong" though? That doesn't even make sense; your experience is what it is. I only said your reasoning about your experience was wrong, i.e. you should be blaming the applications and not the OS (whether they're made by MS or anyone else). Regarding antiviruses: yes, of course I am. That's why they should be opening the files with FILE_SHARE_DELETE, and properly handling the edge cases. Unless you're telling me it's impossible (which I strongly suspect isn't the case, but then again I've never tried to write an AV myself), I don't see how it's the OS's fault. This flag and the associated functionality obviously exists for a reason, right? It's not an OS design flaw if people aren't using it, is it? People can refuse to play along with anything... that doesn't mean the OS is flawed.
  - asveikau 10y ago
    Sharing modes don't help with the STATUS_DELETE_PENDING issue. Nor does it let you delete a directory while children are open. Also some AV will duplicate your handles, meaning they get the same sharing mode you asked for. > This flag and the associated functionality obviously exists for a reason, right? It's the kind of stuff that sounds reasonable when you hear about it, but when you see it put into practice is the source of way too many bugs.
    - wfunction 10y ago
      > Sharing modes don't help with the STATUS_DELETE_PENDING issue. Maybe I misunderstood the problem. But I think my reasoning holds regardless? To be clear, it seems you're talking about a situation where an app is trying to delete and re-create a file, and an AV is scanning the file in between, hence a recreation fails. But with their file system filter drivers, AVs can detect such recreation attempts, so they should be able to handle it properly. So isn't it their fault for not doing so? > Nor does it let you delete a directory while children are open. Right, but same as above: there exists functionality to detect this, right? So if it isn't used, whose fault is it?

asveikau 10y ago

You're funny. Telling me my years of experience of this behavior biting me in the rear end is "wrong". There isn't even such thing as "my files" and not. Are you aware that many people run antivirus products that sit between you and the filesystem and might choose to also open "my" files in an asynchronous fashion based on my own actions? That such an antivirus product has been built into Windows for some time now? (msmpeng.exe) Suddenly that file you thought it safe to have exclusive access to... it wasn't. Even controlling your own actions is hard and yields unexpected results all the time. Almost any time setting dwShareMode to something other than 0x7 and I saw it bite me in some unexpected way due to things my own process is doing, that I did not think of ahead of time. Once you have Windows filesystem code doing this at any appreciable scale you will see this. It takes enough of seeing sharing violations and delete pending errors time after time to realize these are just dangerous patterns on the platform, avoid them and move on.

wfunction 10y ago
I didn't say your experience was "wrong" though? That doesn't even make sense; your experience is what it is. I only said your reasoning about your experience was wrong, i.e. you should be blaming the applications and not the OS (whether they're made by MS or anyone else). Regarding antiviruses: yes, of course I am. That's why they should be opening the files with FILE_SHARE_DELETE, and properly handling the edge cases. Unless you're telling me it's impossible (which I strongly suspect isn't the case, but then again I've never tried to write an AV myself), I don't see how it's the OS's fault. This flag and the associated functionality obviously exists for a reason, right? It's not an OS design flaw if people aren't using it, is it? People can refuse to play along with anything... that doesn't mean the OS is flawed.
- asveikau 10y ago
  Sharing modes don't help with the STATUS_DELETE_PENDING issue. Nor does it let you delete a directory while children are open. Also some AV will duplicate your handles, meaning they get the same sharing mode you asked for. > This flag and the associated functionality obviously exists for a reason, right? It's the kind of stuff that sounds reasonable when you hear about it, but when you see it put into practice is the source of way too many bugs.
  - wfunction 10y ago
    > Sharing modes don't help with the STATUS_DELETE_PENDING issue. Maybe I misunderstood the problem. But I think my reasoning holds regardless? To be clear, it seems you're talking about a situation where an app is trying to delete and re-create a file, and an AV is scanning the file in between, hence a recreation fails. But with their file system filter drivers, AVs can detect such recreation attempts, so they should be able to handle it properly. So isn't it their fault for not doing so? > Nor does it let you delete a directory while children are open. Right, but same as above: there exists functionality to detect this, right? So if it isn't used, whose fault is it?