wrun: can't translate a WSL VolFs path to a Win32 one

[poma]

This happens when I run wrun notepad from a home dir. Maybe just print a warning and fallback to some default path?

[xilun]

A default path (%USERPROFILE%) can be explicitly required by adding an extra param ':' before the command.

For example you can try:

wrun : notepad

(or wstart : notepad to not wait for notepad termination)

':' is a little weird, the reason for it is that I originally wanted to use ~ like bash.exe, but ~ is expanded by bash, so I switched to ':' which is forbidden in Windows paths but otherwise a normal character in parameters as parsed by bash.

I probably won't add an automatic fallback to %USERPROFILE%, because this would be dangerous if you shoot something like wcmd rd /S /Q toto.

[xilun]

Commit e7a048e documents the ':' param.

[goreliu]

What about translating /home/xxx to /mnt/c/Users/%username%/AppData/Local/lxss/home/xxx, and /{etc,usr,xxx} to /mnt/c/Users/%username%/AppData/Local/lxss/rootfs/{etc,usr,xxx} ?

Just a sample used by myself:

diff --git a/caller/wrun.c b/caller/wrun.c
index ed99a21..43179e3 100644
--- a/caller/wrun.c
+++ b/caller/wrun.c
@@ -128,6 +128,23 @@ static char* agetcwd()
         sz *= 2; if (sz > MY_DYNAMIC_PATH_MAX) sz = MY_DYNAMIC_PATH_MAX;
         buf = xrealloc(buf, sz);
     }
+
+    if (strncmp(buf, "/home/", 6) == 0) {
+        const char* rootdir = "/mnt/c/Users/goreliu/AppData/Local/lxss";
+        char* newbuf = xmalloc(sz + strlen(rootdir));
+        strcpy(newbuf, rootdir);
+        strcat(newbuf, buf);
+        free(buf);
+        buf = newbuf;
+    } else if (strncmp(buf, "/mnt/", 5) != 0) {
+        const char* rootdir = "/mnt/c/Users/goreliu/AppData/Local/lxss/rootfs";
+        char* newbuf = xmalloc(sz + strlen(rootdir));
+        strcpy(newbuf, rootdir);
+        strcat(newbuf, buf);
+        free(buf);
+        buf = newbuf;
+    }
+
     return buf;
 }

I don't know how to find the %username% in WSL, maybe outbash.exe can write it to ~/.config/cbwin/outbash_username.

[xilun]

We are not supposed to write in those directories from Win32.

[poma]

quote from stackoverflow

New files that are created via Windows Explorer are possibly not appearing in bash because they are missing special LXSS NTFS attributes.

When LXSS creates files in the LXSS root, it attaches additional information to them via NTFS attributes to store things that cannot be represented by the standard NTFS attributes, such as Linux file permissions. If these are missing, it the files don't show up.

This is supported by the fact that if you make a file in bash, and then make a copy of it with Windows Explorer, it appears in bash. This is presumably because all of the special LXSS attributes were duplicated with the file.

The LXSS filesystem layer also appears to cache the file system, so the directory entries in bash will not reflect the actual state of the file system if files are added or deleted until all bash terminals are stopped (which ends the LXSS session in the LXSS service and hence clears the cache).

So this is only good for reading files.

[goreliu]

@poma I can create a file in WSL and read or edit it with Windows software, like this:

goreliu@MY-PC:~
$ n ahk                     # cp ~/.templete/ahk.ahk .
goreliu@MY-PC:~
$ np ahk.ahk            # wstart c:/mine/app/notepad++/notepad++.exe ahk.ahk

I didn't meet any problems. I don't want to create files in /mnt/xx because I can't use chmod there, every file is 0777.

[xilun]

Only reading files from Win32 should cause no problem as long as they are not written in a concurrent WSL session.

The result of writing files there from Win32 depends on a lot of factors, and to simplify shall not considered reliable -- and even in situations where there currently are a set of conditions that gave you good results in the finite number of tests you did, by principle of how we have been told the architecture of WSL is we should consider that the precise conditions are susceptible to change in new builds. For example, the content of the file observed from WSL might already be stall under some sequences of operations, and if WSL caching is changed in VolFs those exact "safe" and "unsafe" sequences of operations will change.