In r338216 and https://reviews.llvm.org/D49860 we permitted MoveFileEx to copy between volumes -- but before it can, the more posix-y rename_internal fails. Allow rename_handle to fall back on MoveFileEx for this specific error.
Details
- Reviewers
stella.stamenova JDevlieghere zturner - Commits
- rG3fd44a109d5e: Merging r338841: --------------------------------------------------------------…
rG019406554b28: [Windows FS] Allow moving files in TempFile::keep
rL340030: Merging r338841:
rL338841: [Windows FS] Allow moving files in TempFile::keep
Diff Detail
- Repository
- rL LLVM
Event Timeline
I don't have a strong opinion, but I wonder if it would be better to map ERROR_NOT_SAME_DEVICE to errc::cross_device_link and to map ERROR_CALL_NOT_IMPLEMENTED to errc::operation_not_supported. Then you could just say if (EC == errc::cross_device_link || EC == errc::operation_not_supported)
Can't we change dsymutil to create its temporary file in the same directory as the destination?
I'm not sure that's the best solution. Even if we fix it for dsymutil, this seems to be a more general problem of LLVM not supporting cross-device renames. We can't control where a user's temp dir will be or what drive they're running LLVM from. So I think it's important to handle this case.
But if we change the TempFile API so that it always creates the temporary in the same directory as the destination, that becomes a non-problem, no?
My understanding of the TempFile API is that it might not know whether a file is kept or the destination it might be kept to, at the time of creation.
IMHO, this comes down the support code not currently providing a "move", hence this patch. However with this patch unix-rename and windows-rename might behave differently.
The more technically consistent solution could be to mirror Jonas' cross-device copy in https://reviews.llvm.org/D49860 TempFile::keep for Windows. The problem is then just code duplication (and a lack of "move"), rather than functions behaving differently.
I'll upload a patch that does that in a moment to demonstrate.
This revision works just as well as the previous, but keeps "rename" behaving the same. Some future refactor could introduce a "move" function, this is the minimum change for now.