On Fri, Sep 10, 2021 at 5:04 PM Thomas Munro <thomas.mu...@gmail.com> wrote: > On Tue, Sep 7, 2021 at 7:00 PM Alexander Lakhin <exclus...@gmail.com> wrote: > > 07.09.2021 09:05, Michael Paquier wrote: > > > On Tue, Sep 07, 2021 at 09:00:01AM +0300, Alexander Lakhin wrote: > > >> The new approach looks very promising. Knowing that the file is really > > >> in the DELETE_PENDING state simplifies a lot. > > >> I've tested the patch v2_0001_Check... with my demo tests [1] and [2], > > >> and it definitely works.
Since our handling of that stuff never really worked the way we wanted (or if it did, then Windows' behaviour changed, possibly well over a decade ago, from what I could dig up), this isn't an open item candidate for 14 after all, it's a pre-existing condition. So I propose to push this fix to master only soon, and then let it stew there for a little while to see how the buildfarm Windows variants and the Windows hacker community testing on master react. If it looks good, we can back-patch it a bit later, perhaps some more convenient time WRT the release. I added a CF entry to see if anyone else wants to review it and get CI. One small detail I'd like to draw attention to is this bit, which differs slightly from the [non-working] previous attempts by mapping to two different errors: + * If there's no O_CREAT flag, then we'll pretend the file is + * invisible. With O_CREAT, we have no choice but to report that + * there's a file in the way (which wouldn't happen on Unix). ... + if (fileFlags & O_CREAT) + err = ERROR_FILE_EXISTS; + else + err = ERROR_FILE_NOT_FOUND;