On Thu Dec 4 10:04:17 2025 +0000, eric pouech wrote:
Added. I don't think there's a meaningful error here other than the file already existing. (Which, to be fair, was an error in my original patch. I've changed FILE_OPEN_IF to FILE_CREATE.) mklink /j, unlike the other variants, doesn't validate the destination at all. thanks for the update... looks good (yes the non existing target is the one I had in mind)
also, native cmd doesn't handle path:s longer than MAX_PATH characters, so this shall be detected and failed upon
According to my testing it does here, actually. retested with: [mklink-cmd.patch](/uploads/fc70ee6d2b13278afe842605c9622590/mklink-cmd.patch) here native (Win10) fails when target is larger than MAX_PATH (didn't try to check that the very value of the limit though) (and your MR crashes because of a buffer overflow when setting file2) replying to and correcting myself
updated version of the test (looks like long target in first version of the test was failing for other reasons) [mklink-cmd.patch](/uploads/6fc5eadd257bb5fb23121a2c42907806/mklink-cmd.patch) what seems to happen: * native accepts and supports target path larger than MAX_PATH (that's likely what you were referring to) * but the absolute path of the created entry by mklink shall not be larger than MAX_PATH (and in fact even lower than that, cf the 'cd..' in tests, didn't investigate further (\*)). IMO we want to ensure that if 'mklink /j whatever foobar' succeeds, then 'rmdir whatever' will also succeed (and not fail because of a too long path) * added also a test for checking that even with a target path longer than MAX_PATH 'cd' to that target works (here the absolute destination path is smaller than MAX_PATH, I would have liked to test also a larger one, didn't went further) (\*) one hyp would be that since target length is longer than MAX_PATH, native moves from DOS paths to NT paths still keeping the MAX_PATH limit (but that's just wild thinking) -- https://gitlab.winehq.org/wine/wine/-/merge_requests/9595#note_124678