https://bugs.winehq.org/show_bug.cgi?id=50770
--- Comment #9 from Martin Storsjö martin@martin.st --- (In reply to Erich E. Hoover from comment #8)
(In reply to Hans Leidekker from comment #7)
... Right, but this also means that if you report Unix symlinks as NT symlinks you don't know what type they are when the target doesn't exist.
That's correct, right now I'm treating dangling unix symlinks as files: https://github.com/wine-staging/wine-staging/blob/ 3790a7051055e36ef8112c1b0b5e111e0ee7a0ab/patches/ntdll-Junction_Points/0035- ntdll-Treat-undecoded-unix-symlinks-as-NT-symlinks.patch#L91
However, for symlinks an application didn't create itself they have to check whether they're a file or a directory before deleting them (so as long as we treat them consistently on our end then this will work correctly). You only run into problems with file/directory symlinks when an application creates them a certain way and assumes they stayed that way (doesn't check what type they are before deleting).
Right, as long as this only is an issue with dangling symlinks, it might not be that big an issue...
And a file/dir/symlink agnostic way of deleting things, CreateFile(path, DELETE, FILE_FLAG_OPEN_REPARSE_POINT), SetFileInformationByHandle(FileDispositionInfo, FILE_DISPOSITION_INFO::DeleteFile = TRUE), should work in either case.