[PATCH] D111875: [Support] [Windows] Manually clean up temp files on network shares

[Martin Storsjö via Phabricator via llvm-commits]

mstorsjo updated this revision to Diff 380774.
mstorsjo added a comment.

Updated according to what was discussed with @rnk.

I ran into one big surprise regarding this though: If we don't pass `OF_Delete`, we don't set the `DELETE` access mode on the opened file. And without that, renaming the temp file via `SetFileInformationByHandle(FileRenameInfo)` fails. (Renaming it via the fallback codepath `MoveFileEx` succeeds though.) So either we need to always pass `DELETE`, or we'd need to add yet another windows specific open flag, `OF_Deletable` (in addition to the existing `OF_Delete`).

Then on the other hand; if we always end up opening files with `DELETE`, then we could just skip passing `OF_Delete` and try calling `setDeleteDisposition` altogether, and return the result in an output parameter like in the previous iteration (although I guess it can be argued that this approach is cleaner anyway).

Other open questions: I now change `setDeleteDisposition` to error out on a network file system. This is a behaviour change if someone else is using `OF_Delete` on a network file system - but it's probably ok? There are no other uses of `OF_Delete` in the llvm-project monorepo though.

Should we give `RemoveOnClose` an even more explicit name? As it's now unclear whether it says that the OS will implicitly remove it on close, or that we must remove it manually on close. `ManuallyRemoveOnClose` sounds quite inelegant though...


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D111875/new/

https://reviews.llvm.org/D111875

Files:
  llvm/include/llvm/Support/FileSystem.h
  llvm/lib/Support/Path.cpp
  llvm/lib/Support/Windows/Path.inc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: D111875.380774.patch
Type: text/x-patch
Size: 4897 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20211019/cb12e8e4/attachment.bin>