An update: I just re-tried creating a symbolic link from inside wsl on drvfs (case 2). It now created a symlink just as "mklink" does. What might have changed is that I updated to a newer insider preview or that I enabled developer mode when I tried the first time.
[1] seems to apply for case 1. [2] has a nice overview about what can happen here. Michael [1] https://github.com/libgit2/libgit2/pull/4713 [2] https://stackoverflow.com/questions/11662868/what-happens-when-i-clone-a-repository-with-symlinks-on-windows Am Do., 2. Mai 2019 um 10:17 Uhr schrieb Alexandre Ganea <alexandre.ga...@ubisoft.com>: > > Thanks Michael, it makes sense. I'm still with the old SVN setup on Windows. > WSL uses the NTFS partition through drvfs (your case 2.) > I'll switch to the git monorepo, it looks like the latest git supports [1] > symlinks on Windows (with the restrictions you've mentioned) and they should > be mapped properly inside WSL in that case. > > Should we then assume symlinks will always work for end-users? Should we > validate that somehow, during cmake setup? > > Alex. > > [1] https://github.com/libgit2/libgit2/pull/4713 > > -----Message d'origine----- > De : Michael Kruse <llvm-comm...@meinersbur.de> > Envoyé : 1 mai 2019 17:23 > À : reviews+d42642+public+5dc9c99d2f2d3...@reviews.llvm.org; Alexandre Ganea > via Phabricator <revi...@reviews.llvm.org> > Cc : hah...@hahnjo.de; jle...@google.com; t...@google.com; Alexandre Ganea > <alexandre.ga...@ubisoft.com>; cfe-commits <cfe-commits@lists.llvm.org>; > llvm-commits <llvm-comm...@lists.llvm.org>; sylvestre.le...@gmail.com > Objet : Re: [PATCH] D42642: [CUDA] Detect installation in PATH > > Hi, > > I had my own difficulties with this. It depends on how the repository > containing the symlink has been checked-out. For instance: > > 1. Using a windows git (such as git extensions, mingw-git, git for windows) > 2. Using git inside wsl on a drvfs mount (i.e. a windows folder > mounted into the Unix filesystem) > 3. Using git inside wsl on a lxfs mount (I.e. native mount such as '/') > > In case 1. git does not create a Ubuntu symlink. Also, there are no > Unix symlinks in Windows filesystems, so when Unix tools (such as git) > request to create a symlink, it creates something else (AFAIR it's a > text file containing the symlink path, but having lost its symlink > properties). Case 3 should work. > > I still managed to make cases 1 and 2 work by deleting the text file > and re-creating it with windows's "mklink" tool (which requires either > admin rights or developer mode turned on). It seems the WSL layer > translates this as a symlink to the Linux environment. > > Michael > > > > > > Am Mi., 1. Mai 2019 um 16:59 Uhr schrieb Alexandre Ganea via > Phabricator via llvm-commits <llvm-comm...@lists.llvm.org>: > > > > aganea added a subscriber: rnk. > > aganea added a comment. > > > > So it turns out this is a symlink issue. The file > > `clang/trunk/test/Driver/Inputs/CUDA-symlinks/usr/bin/ptxas` has been > > synchronized on my Windows 10 PC as a regular text file, not a symlink. It > > looks like TortoiseSVN doesn't implement symlinks. As WSL inherits of my > > file system, it will not find the symbolic link. I suppose `REQUIRES: > > !system-windows` isn't enough for `cuda-detect-path.cu`, and it would need > > something like `REQUIRES: symlinks` along with support in lit. @rnk > > > > > > Repository: > > rL LLVM > > > > CHANGES SINCE LAST ACTION > > https://reviews.llvm.org/D42642/new/ > > > > https://reviews.llvm.org/D42642 > > > > > > > > _______________________________________________ > > llvm-commits mailing list > > llvm-comm...@lists.llvm.org > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits