elieux
commented
8 years ago The Cygwin try_to_bin ("move file away if it can't be deleted right away") function that allows overwriting open files is not smart enough to solve this. I've discussed this with Cygwin maintainers and we have a proposed solution waiting to be implemented. I may try implementing it at some point, but no promises :).
Citing Corinna (hopefully not against her will):
off the top of my head, we might be able to workaround the problem if we replace the call status = NtQueryInformationFile (fh, &io, pfni, 65536, FileNameInformation); with a call to status = NtQueryObject (h, ObjectNameInformation, poni, 65536, &size); with typeof(poni) == POBJECT_NAME_INFORMATION this returns the path as "\Device\HarddiskVolumeX\foo\bar" this obviously affects some code later on, e. g. the test "pfni->FileNameLength == 2" wouldn't work anymore the tests definitely gret more complicated network paths are returned as "\Device\Mup\server\share..." you get the idea, I guess
FrankHB
yumetodo
mingwandroid
Lets assume I've installed MSYS2 to:
C:/Junction/msys64/, where Junction/ points toD:/Stuff/the execution ofpacman -S pacmanthen fails withbecause it wasn't aware of the junction.
Yet if msys64/ itself is a junction, it would actually work as it seems to resolve the junction/symlink in that case. This is also true if you let
C:/Junctionpoint to the entire driveD:/(so you go like C:/Junction/Stuff/msys64) Also, if you create a junctionD:/AnotherJunction/which points toC:/Junction/msys64/you can actually see what happens internally:You can see that it resolved the first junction which was the msys64 "root" (
D:/AnotherJunction/) but didn't resolve the actual full path.I've opened this issue following a discussion in #524 as my issue wasn't really related to that one. (just a side note as it annoyed me in the past) So check that other issue for my initial "report" and my there described msys2 update issues.