
Do not change Linux files using Windows apps and tools - nikbackm
https://blogs.msdn.microsoft.com/commandline/2016/11/17/do-not-change-linux-files-using-windows-apps-and-tools/
======
mevile
In this comment thread there are many people who did not read the entire
article to its conclusion, and then also failed to read the many comments
about the very last and very important bit at the end of the article.

There ought to be like a "didn't read the article" link next to the comment
people can click to quickly bury those comments. It would avoid people having
to reply again and again to say the same thing that commentator could have
just learned had they read the article. Especially, you know, this bit:

> Remember: There’s a reason we gave the %localappdata%\lxss\ folder ‘hidden’
> & ‘system’ attributes

There are multiple comments in this thread right now with that line in them.

~~~
hueving
>There ought to be like a "didn't read the article" link next to the comment
people can click to quickly bury those comments.

There is, it's the downvote button. The distinction of why a downvote is
useless.

~~~
aaron695
> The distinction of why a downvote is useless.

Actually I think it would be incredible useful.

You could use it to shift a community to a more useful direction.

A more direct way of eliminating common errors.

If on a cool new tech that's renewable if someone starts another bloody global
warming discussion being able to downvote as OT could try and keep people on
topic rather than having to down vote something you agree with.

There are issues with the idea, it can become censorshop, but I find it an
interesting one.

~~~
brazzledazzle
They could just make flagging dual purpose. But flagged comments probably
alert the admins. Maybe clicking the flag button could spawn a drop down but I
think there might be an aversion to introducing complexity and impedance.
Requiring multiple clicks and using drop down elements might be a departure
from the deliberate simplicity.

------
bphogan
FTA:

> I have to provide this guidance at least 2-3 times a day so instead I am
> publishing it here so everyone can find / link-to this guidance.

This may be oversimplifying, but if that's the case, then there's a design
problem. Either you should make it work, or you should do some better defense
against it up front.

If the solution is "eh, just work out of a Windows folder", this isn't really
better than using a VM. Heck, I've been using WSL since the beta, and using
Vagrant + Putty gives me better results.

I was hopeful it would get better, but then I saw this post and shook my head.
"Silly users, stop trying to do things we didn't plan for you to do!"

~~~
vesinisa
EDIT: Misinformed, see wfunction's comment below.

I can understand their frustration, because this is probably really hard to
fix.

I guess there would not be problems if Windows apps were not overwriting files
by first deleting them and then re-creating them with new contents. It's easy
to see why this leads to data loss (file permission metadata _is_ data in the
Unix world). You rarely see Unix apps re-creating files: there you instead you
specify the behaviour in case the file exists with the flags of the open(2)
call.

I guess such contract is absent / not as strict in the Windows world (disc: I
have never programmed for Windows), which would make solving the conflicting
APIs almost impossible: if a re-created file would inherit a previously
deleted synonymous file's permissions, what happens to a program who is
deleting a file exactly to get _rid_ of its permissions?

I think MS has done pretty impressive work with the Linux subsystem. It is
certainly not a trivial task, and I am looking forward to seeing more awesome
stuff running on Windows.

~~~
wfunction
> You rarely see Unix apps re-creating files: there you instead you specify
> the behaviour in case the file exists with the flags of the open(2) call.

I think your lack of knowledge about this problem is betraying you. This is
outright wrong. First, look up CreateFile() in Windows; it has flags to
specify things like this as well. Second, the reason programs delete files in
the first place has nothing to do with the lack of such flags. It has to do
with the fact that they want to write new contents but don't want to lose data
in the event of an abnormal termination. If you truncate the file that you're
opening instead, then you lose that data if something goes wrong. So they
create a new file and replace it with the old one when it's written.

Finally, as far as I know, 'nix tools have a tendency to outright replace
files MORE than Windows tools do. That's why the underlying Windows kernel API
function (NtCreateFile/ZwCreateFile) has a FILE_SUPERSEDE parameter... whose
_entire intention_ is to mimic POSIX behavior:

> The CreateDisposition value FILE_SUPERSEDE requires that the caller have
> DELETE access to a existing file object. If so, a successful call to
> ZwCreateFile with FILE_SUPERSEDE on an existing file effectively deletes
> that file, and then recreates it. [...] Note that this type of disposition
> is consistent with the POSIX style of overwriting files.

[https://msdn.microsoft.com/en-
us/library/windows/hardware/ff...](https://msdn.microsoft.com/en-
us/library/windows/hardware/ff566424.aspx)

~~~
asveikau
I would go so far to say (though I've met few people who grok this, as Windows
filesystems is pretty rare as a specialty these days) that delete-and-recreate
is a huge antipattern and recipe for failure on Windows.

The reason: Delete behavior.

In NT, when you delete a file and handles are open, the name sticks around
until all handles are closed. Any attempt to re-open (including re-create)
with the same name will fail with STATUS_DELETE_PENDING while this is the
case.

Combine that with the fact that most operations in NT (including delete or
rename) happen via opening handles to the file first and you have lots of
chaos and race conditions.

So the delete + recreate pattern is very likely to bite you later as a "re-
create fails randomly".

~~~
wfunction
OK, so let me explain why your reasoning is wrong.

The problems here only occur if your app is modifying files that do not
"belong" to it. For apps that store config files, databases, etc., these
problems should not arise, because those files should only be touched by those
apps, and (a) the app is already aware what metadata the file should have and
is the one maintaining control over the files, and (b) the app can make sure
that it is never using a file that it is trying to delete. If the user is
messing with the app's files, then the user is just as responsible for not
preventing their deletion as he/she is responsible for not corrupting their
contents. You can't blame the deletion behavior for that; the responsibility
for proper care rests entirely on the user, and having a different delete
behavior doesn't fix the core problem.

For files that _don 't_ belong to the app, the situation is entirely
different. First, apps should not be deleting files that don't belong to them
without user consent. And if the user is consenting, the user is responsible
for ensuring this does not cause problems. Second, those that modify files
they do not own are responsible for all aspects of this, including preserving
metadata. This is of course difficult and quite a burden, but at this point,
it is considered a bug in the application if it does not do this correctly.
Again, the app is the one mucking with files that it does not own, so the app
and the user together are responsible for maintaining consistency, not the OS.

~~~
asveikau
You're funny. Telling me my years of experience of this behavior biting me in
the rear end is "wrong".

There isn't even such thing as "my files" and not. Are you aware that many
people run antivirus products that sit between you and the filesystem and
might choose to also open "my" files in an asynchronous fashion based on my
own actions? That such an antivirus product has been built into Windows for
some time now? (msmpeng.exe) Suddenly that file you thought it safe to have
exclusive access to... it wasn't.

Even controlling your own actions is hard and yields unexpected results all
the time. Almost any time setting dwShareMode to something other than 0x7 and
I saw it bite me in some unexpected way due to things my own process is doing,
that I did not think of ahead of time.

Once you have Windows filesystem code doing this at any appreciable scale you
will see this. It takes enough of seeing sharing violations and delete pending
errors time after time to realize these are just dangerous patterns on the
platform, avoid them and move on.

~~~
wfunction
I didn't say your experience was "wrong" though? That doesn't even make sense;
your experience is what it is. I only said your reasoning about your
experience was wrong, i.e. you should be blaming the applications and not the
OS (whether they're made by MS or anyone else).

Regarding antiviruses: yes, of course I am. That's why they should be opening
the files with FILE_SHARE_DELETE, and properly handling the edge cases. Unless
you're telling me it's impossible (which I strongly suspect isn't the case,
but then again I've never tried to write an AV myself), I don't see how it's
the OS's fault. This flag and the associated functionality obviously exists
for a reason, right? It's not an OS design flaw if people aren't using it, is
it? People can refuse to play along with anything... that doesn't mean the OS
is flawed.

~~~
asveikau
Sharing modes don't help with the STATUS_DELETE_PENDING issue. Nor does it let
you delete a directory while children are open.

Also some AV will duplicate your handles, meaning they get the same sharing
mode you asked for.

> This flag and the associated functionality obviously exists for a reason,
> right?

It's the kind of stuff that sounds reasonable when you hear about it, but when
you see it put into practice is the source of way too many bugs.

~~~
wfunction
> Sharing modes don't help with the STATUS_DELETE_PENDING issue.

Maybe I misunderstood the problem. But I think my reasoning holds regardless?
To be clear, it seems you're talking about a situation where an app is trying
to delete and re-create a file, and an AV is scanning the file in between,
hence a recreation fails.

But with their file system filter drivers, AVs can detect such recreation
attempts, so they should be able to handle it properly. So isn't it their
fault for not doing so?

> Nor does it let you delete a directory while children are open.

Right, but same as above: there exists functionality to detect this, right? So
if it isn't used, whose fault is it?

------
captainmuon
Fun fact: the linux metadata is stored in a little known NTFS feature called
"extended attributes" (EA), which is not the same as alternate data streams.
You need to use a pretty obscure API to access them. I started writing a tool
to do so, only to find that someone already did, including a decoding of the
(binary) EAs (which basically contain Linux uid, gid, permissions, ctime I
think):

[https://www.reddit.com/r/bashonubuntuonwindows/comments/52w8...](https://www.reddit.com/r/bashonubuntuonwindows/comments/52w86h/lxssattr_a_very_basic_stat_of_sorts_to_show_linux/)

There is currently no tool that _writes_ the EAs. It should be not too hard to
write one, however it won't work transparently - WSL maintains a cache of this
metadata, so you'd likely have to quit all WSL applications before you make
any changes to avoid corruption.

~~~
j_s
LXSS extended file attributes viewer

[https://github.com/dmex/lxssattr](https://github.com/dmex/lxssattr)

\- the actual project for the decoder

------
mastazi
Honestly, this should be obvious for anyone who has at least a bit of
experience with Linux. It's the same reason why you use tar.[extension] when
you create an archive - Tar saves the Linux metadata (ownership, permissions).

To those who claim this need to be fixed, I want to ask: how? I mean if I
modify a file in the Linux filesystem as a Windows user, what should the
ownership be? Root? Some non-root user? Should we just make those files 777?
Each of those solutions would bring more problems. It seems to me that there
is no "one size fits all" fix here.

~~~
userbinator
_I mean if I modify a file in the Linux filesystem as a Windows user, what
should the ownership be?_

Inherited from the directory, like it is on Windows and Linux (by default)?
And 777 is a perfectly fine default, since it's a good match for the Windows
default attributes and ACLs.

 _It seems to me that there is no "one size fits all" fix here._

There isn't. But there _is_ a sensible default, which is _not_ "assumes the
file is corrupted/damaged".

Consider what happens in Linux if you mount a filesystem like FAT which
doesn't even support all the extended metadata. No extended metadata does
_not_ mean "I can't do anything with the files", unlike what seems to be
happening with WSL here.

~~~
dozzie
> Inherited from the directory, like it is on Windows and Linux (by default)?

Who lied you such horribly that under _any_ unix a newly created file is owned
by the owner of the directory? It's not even generally true for group
ownership, which has a little more frivolous behaviour!

> And 777 is a perfectly fine default

0777 permissions are _never_ fine as a default. It's asking for security
vulnerabilities.

------
hs86
Recently I tried to cut corners by copying my ~/.ssh from Cygwin into my WSL-
user's home directory with the Windows Explorer and wondered why the folder
was not visible from within WSL. cp-ing it from within WSL's /mnt/... solved
the issue but left me still wondering. At least this post confirms that there
be dragons, if I move files manually into the lxss folder.

~~~
JoBrad
I added some commands to my .bashrc that syncs my config files when I login.

------
willtim
To be fair cygwin has a similar problem. It attempts to map Unix permissions
to NT and gets confused if Windows apps modify the permissions.

~~~
qwertyuiop924
But this happens even if window tools _don 't_ change permissions. That is
awful.

------
fetbaffe
So many people in this thread that think that this is the end of WSL and you
should use Cygwin instead. Laughing.

Cygwin is awful compared to WSL. Poor performance, always gotchas, cygpath
handling etc. Sure it was a good option back in the day and a good engineering
feat.

With WSL I get an environment that behaves exactly like Linux, complete POSIX
without gotchas.

I work with WSL all the time on files located on Windows partions. Works
perfectly. Just create symlinks in WSL to Windows folders and you are ready to
go.

Why do people even need to work with files in the hidden system folder? The
only files that I maybe want to change from Windows to WSL would be .bashrc et
al, but just copy it or edit them from WSL and problem solved.

If I don't want to use WSL and I only need a shell, then MSYS2 is the way to
go, handles Windows and POSIX paths interchangeably without the cygpaths
hassle.

And no, WSL is not like SFU, that never really worked.

~~~
ezy
Honestly, as weird as cygwin can be, I question the judgement of relying on
Linux's chief competitor to keep a mock linux kernel interface as well
supported as the OS they _really_ care about. Are you really sure that
environment will be working in Windows 11... windows 12? etc?

This just seems like a really bad idea compared to simply running a VM and
sharing a filesystem using networking or other means... It's not like a modern
machine, even a shitty netbook nowadays, can't handle a virtualbox instance,
or localhost networking.

~~~
fetbaffe
Microsoft of today is not a software company, they are a service company. So
how their services are delivered, from a competitor for example, is not that
relevant anymore.

But assume you are 100% right that the WSL environment is removed or stops
working in Windows 11+, how is that affecting my Linux experience with WSL
today? Not one bit, because if it would change in the next release I can when
i happens start a Virtualbox, but why run it now and have inferior experience
when the result is the same? Does not make any sense. Or I can switch to Linux
even, still same old shell.

------
ChuckMcM
Hah I wasn't the only one reporting this "mis-feature" I bet. I wonder if
Microsoft could license the old NetApp 'unified' protections code that let you
export a volume to both CIFS and NFS.

In my case I pulled a git clone into the Linux side of a project that was
building using a third party gui tool, ran that from windows and my Bash
window got soooo confused.

Seriously though, if they can improve the terminal "behavior" and figure out a
work around for USB device access this will be really stellar.

~~~
alecthomas
Out of curiosity, how is the Linux integration? Does it feel like native, or
is it disjointed like Cygwin always has?

~~~
ChuckMcM
I find it much more useful/natural than cygwin. The places where it reminds me
it isn't Linux is when something wants to create a Unix domain socket (screen)
or needs access to /dev or something like that. CPAN works fine as does ssh
and most things I use from the command line (gcc embedded and make, vim, etc).
Nothing that would pop up an xwindow works (as expected).

~~~
bitcrazed
In more recent Windows Insider builds, Tmux & Screen now work correctly, as
does network connection enumeration (e.g. via ifconfig), sshd works as
expected, along with MySQL, Apache, nginx, etc.

~~~
ChuckMcM
I am clearly very excited that you seem to be making this a 'real' thing
rather than just a talking point. You realize there is a 'usb over ethernet'
spec right? And using that and a windows service on a local socket on the
windows side you could arbitrate exclusive access to plugged in USB devices to
the Bash shell user right?

------
jxy
"Windows deleted my homework…"

Seriously, is mounting files readonly that hard to do? If you can't deal with
linux files, leave them alone.

~~~
matt_wulfeck
You sound like the kind of engineer that keeps software perpetually stuck in a
UX nightmare.

"Of course it doesn't work that way, idiot! If only you read the obscure
documentation and had years of experience like me you'd understand why you're
the problem and not the software!"

~~~
TheCapn
I mean.... the article does point out:

Remember: There’s a reason we gave the %localappdata%\lxss\ folder ‘hidden’ &
‘system’ attributes

You gotta work your way around a couple mild safeguards to go fucking with
things.

~~~
matt_wulfeck
Anything that has the potential to corrupt your filesystem should come with a
_huge_ disclaimer.

~~~
wvenable
Like the system flag? You can make any OS unbootable with the same level of
permissions. This is particularly mild given what we can do by ignoring these
warnings as an administrator.

------
hartator
It sounds bad but WSL is working really good, but yeah use '/mnt/c' to share
files between the 2 systems. It actually comes organically.

~~~
softawre
You have it backwards. The problem is changing linux files with windows
editors.

~~~
Whitestrake
The problem is changing Linux files that are currently stored in
%localappdata\lxss\ using a Windows tool.

Changing Linux files that are stored in C: and are accessed in Windows from C:
and in Linux from /mnt/c/ is fine.

------
klagermkii
This is a pity. One of the things I like with the Mac is being able to use
Mac-side editors like BBEdit to be able to make changes to the configuration
and files of the Unix-y server tools I need. If I can't reliably use Windows
GUI editors that would limit my ability to migrate from macOS.

If one is running NGINX/PHP under WSL would one not even be able to safely
edit .php files?

~~~
kej
The lxss folder is for things you only want to access from Linux. Things like
a .php file you want to access from both sides goes somewhere else. In Windows
you go to C:\MyPHPFiles and in Linux you go to /mnt/c/MyPHPFiles.

~~~
sbuttgereit
This. I use WSL daily and edit in both Linux & Windows... but the files I'm
dealing with are in a directory structure that set up on the windows side and
I get to them through /mnt/<drive letter>. Completely painless for me.

I do have to occasionally edit Linux config files and whatnot and, yes, I do
that with emacs or vim (depending on mood), but it's honestly not often and I
personally prefer the terminal based editors in Linux for that better (yeah, a
preference thing there... ).

Anyway, been working like this since before the Anniversary Update on the
later insider builds and it's been pretty solid and seamless for me.

~~~
nickjj
Have you tried using an xserver to run GUI Linux apps through it? If so, how's
the delay? Is it instant and ready for full time development?

Use case would be wanting to use an editor that can take advantage of
programming runtimes installed on the Linux side of things.

Think about using Sublime, where you'd want to run a Python linter. In this
case Sublime needs to be installed and ran in Linux alongside your Python
installation.

~~~
reynoldsbd
I use Xming and it works pretty seamlessly for both local applications and
X-forwarded ssh sessions

~~~
nickjj
Nice, is that the free version of xming?

I had ~3 seconds of typing delay and a lot of visual graphical tearing on an
i5 with an SSD and plenty of RAM (with SSH compression enabled) when I tried
to use it on a locally running vmware VM under Windows 8 but I can't test it
on 10.

Is it purely instant on 10, to the point where you would feel happy typing /
looking at it all day?

------
SwellJoe
I ran into this problem within days of starting to use Bash on Windows. Had
several files just disappear, though I didn't need to reinstall anything (so
far). They should really document this issue better, like in the docs for
installing WSL.

~~~
ocdtrekkie
In fairness, as the author points out, the files are hidden and marked as
"system". People tinkering with files flagged system are usually going to have
a bad time. You have to specifically go digging for this, and then decide you
want to mess with it.

Microsoft's platform design is generally open enough to allow you to do dumb
things. This is a good thing, because you can reg-hack your way around
problems with the OS. But like editing the registry, doing so is very much at
your own peril, it's really not designed to be tampered with by users.

~~~
mcbits
I don't think it's fair to blame people for thinking they could edit simple
text files under that folder, well-hidden as it is. How many people already
knew there would be any issues beyond line endings (not counting those who
learned by breaking things)? I sure didn't. It's pure luck that I hadn't tried
it yet.

~~~
ocdtrekkie
It's absolutely fair. To even SEE these files, there's a warning you must
click through that notifies you that you can cause significant harm to your
system if you modify them. So when one does so, and then one modifies them...
one should definitely expect to cause significant harm.

People who enable visibility on protected system files and then act upset that
messing with protected system files breaks things, are the sort of reason we
don't give out admin rights where I come from.

~~~
SwellJoe
Hmm...none of that matches my experience. I opened them from Powershell or git
bash and from Atom, maybe vim was involved. I don't remember the process of
getting there, but I do remember it being tricky to find the directory where
the Linux environment lived, but, maybe, a grep or find was involved. Windows
Explorer was not involved.

I'm a 20+ year Linux user. I use Linux tools to find things and to navigate
places. I guess if I were a Windows user, who does things in the usual Windows
way, I might have received a warning of some sort.

I'm just saying it'd be cool if there were a warning somewhere in the docs
about this issue. It wasn't something I expected. I mean, I don't have to
worry about editing "Windows" files on my Linux system with WINE. And, I'm
able to mount my Windows partition from Linux and edit files without fear of
harming things. I assumed things worked the same way for WSL. It was a wrong
assumption, but I don't feel like it means I'm stupid to have made it, based
on the knowledge I had at the time.

~~~
wvenable
> I'm just saying it'd be cool if there were a warning somewhere in the docs
> about this issue.

If you find any docs about this folder from Microsoft, you will find that they
do warn you about exactly this.

"Interoperability between Windows applications and files in VolFs is not
supported." \-- Microsoft

~~~
SwellJoe
I wasn't looking for docs on a folder, I was looking for docs about WSL (of
which there were none other than the blog post about how to install and enable
it, at the time). It's beta software, and I'm not complaining (my review of
WSL at the time commented on this problem, without knowing it was a known
issue, and I just said something to the effect of, "I won't do that again!"
rather than "I'm gonna burn down Microsoft for doing this to me!").

It's no big deal, really. I didn't expect miracles, and it all works much
better than I expected. I wish the interop were better, but I'm pleased it's
even something Microsoft is trying to do.

~~~
wvenable
That quote comes from here:

[https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-
subs...](https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-
for-linux-overview/)

But I suspect they specifically wouldn't mention it because it's an
implementation detail people aren't supposed to know about or look into. The
problem might have been more widespread had they actually said "Don't change
anything in this specific hard to find hidden/system protected folder"

~~~
SwellJoe
Cool. I might have even read that at some point in the process and lacked
enough understanding of the system to know what it meant. I found the process
of getting WSL installed quite confusing, so maybe I was distracted. But,
reading it even now, it doesn't jump out at me that using a Windows app to
mess with Linux files would be disastrous (it was not disastrous for me, but
had the files been important, it would have been, as they disappeared). It
sounds like it's a thing that just wouldn't work;, e.g. Windows apps wouldn't
see them at all, rather than it would potentially destroy your Linux
installation, which is what this blog post indicates can happen.

~~~
ocdtrekkie
Wouldn't your OS not being able to see files from a component on your computer
be even worse?

------
sytelus
TLDR; if you are using BashOnWindows then don't modify files in lxss folder
from Windows or otherwise BashOnWindows will break. Use bash to modify those
files.

------
mcbits
Another thing to watch out for is how you have git configured to handle
newlines. Usually the recommended config under Windows is to have it
transparently change them to \r\n when you clone a project, and back to \n
when you push.

This trips up some Linux tools when you use those files from the Linux
subsystem. Best either turn that feature off or only use the Linux git for any
projects you plan to touch from there, even if you're saving them under
/mnt/... to share with Windows. And of course you'll have to beware of how
your Windows editors are saving those files.

I wish the Windows world had just migrated to UTF-8 and \n 10 years ago. It
would all be smooth sailing by now.

~~~
Const-me
Most Windows apps, both third-party and built-in, support UTF-8 for many
years. Just not by default. You need to specify your data is UTF-8:
[http://unicode.org/faq/utf_bom.html](http://unicode.org/faq/utf_bom.html)

------
sqeaky
Why should an application need to be aware of the file meta data in most
situations anyway? Shouldn't the OS handle the metadata unless the application
specifically requests otherwise?

~~~
willtim
I'm guessing the issue is that many apps use the Windows APIs badly and just
recreate files rather than updating them.

~~~
saurik
Or they use the Windows API well and purposely create new files rather than
updating old ones to get atomic updates (the same way that most editors on
Unix never ever update existing files and instead create new ones on which
they call rename()).

~~~
willtim
Well they obviously aren't checking for metadata / extended attributes when
reading the files.

~~~
lucaspiller
This issue exists on Linux too :-) ext4 supports extended attributes including
the creation time, but most apps blindly rename which means the metadata is
lost.

~~~
KirinDave
I'm glad someone else said it. I was biting my tongue.

------
JorgeGT
According to their UserVoice response, this feature is "in the backlog", so
maybe someday it will be available:
[https://wpdev.uservoice.com/forums/266908-command-prompt-
con...](https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-
on-ubuntu-on-windo/suggestions/13856379-make-wsl-filesystem-accessible-from-
windows#comments)

------
Someone
[https://blogs.msdn.microsoft.com/oldnewthing/20050715-14/?p=...](https://blogs.msdn.microsoft.com/oldnewthing/20050715-14/?p=34923/):

 _" if you delete some file "File with long name.txt" and then create a new
file with the same name, that new file will have the same short name and the
same creation time as the original file."_

It might open a security can of worms, but there might be a safe way to do
that for those essential Linux attributes, too, for example if the program
deleting the file has write permissions on it.

------
brak1
i'm a bit out of the loop - why/how would you be doing this? Windows has a
directory now for linux files?

~~~
djsumdog
Windows 10 has an entire Linux subsystem now. They've implemented the posix
APIs and there are other blog posts where people have gotten things like i3
running natively in Windows. It's only in the preview builds and you have to
specifically enable it.

~~~
xorxornop
Well, um, I'm not running a preview build, but I have it. It's been there
since the Anniversary update

------
krzrak
> Creating/changing Linux files from Windows will likely result in data
> corruption and/or damage your Linux environment requiring you to uninstall &
> reinstall your distro!

It's funny, that this is so Windows-centered advice (regarding the "uninstall
& reinstall"). Fixing things in Windows very often boils down to "just do the
reinstall". In Linux you have lots of other tools and methods to recover from
such disaster.

~~~
ygra
Well, if you're so inclined, you can re-create the NTFS extended attributes on
the file you broke and things should be back to normal. However, the article
is for people who clearly don't know what they're doing, or what they broke
and how, so I think giving the »Have you tried turning it off and on again«
advice is just about right for those folks.

And even on Windows you can fix most issues in different ways than
reinstalling, it's just that for some degrees of brokenness it's by far the
faster solution (cf. just re-cloning a git repository instead of figuring out
what is broken).

------
drieddust
Same goes other way. Modifying windows files on a POSIX system end up creating
incompatibility which aren't easily resolvable. As an example, one can create
a file with a trailing space easily but good luck trying to mamage it using
standard windows tools. I am not sure why MS thinks this is a good idea.

------
wnevets
what is the general opinion of linux for windows so far?

~~~
Eridrus
Quite good and improving regularly. Jupyter finally works right out of the
box.

People are right that it's mostly just like a VM, however, a VM which doesn't
eat up all your memory and is actually fast since there's no VM layer is
actually a pretty nice thing. I run WSL on my laptop with 8GB of RAM, whereas
running VMs is something I generally avoid.

They have started improving the integration a little; you can call bash from
windows and windows executables from bash, if that's useful to you.

The main questions I have are:

a) Will VS Code support WSL? I don't need to edit the files inside the linux
filesystem, but things like running python from an IDE inside WSL don't work
atm. I have to treat it like a remote system.

b) Will we ever get OpenGL/CUDA support?

c) Will developers treat WSL as a first class platform the same way they do
OSX, so that it's not the end user who has to come up with workarounds?

Having said that, I'm a huge fan and I use it a lot. But I also keep real
linux machines around since not everything is handled by WSL.

~~~
jackhammons
I work on WSL.

A) VS code supports WSL in the newer versions of Windows Insider Builds.[1]
Support for individual IDEs is now available [2] but will take time for
individual IDEs to implement.

B) This is something that we are actively looking at but it is not an easy
problem and will take time.[3]

C) ¯\\_(ツ)_/¯ We certainly hope so.

[1] [http://pjdecarlo.com/2016/06/bash-on-windows-as-
integrated-t...](http://pjdecarlo.com/2016/06/bash-on-windows-as-integrated-
terminal-in-visual-studio-code.html)

[2] [https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-
and-...](https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-
interoperability/)

[3] [https://wpdev.uservoice.com/forums/266908-command-prompt-
con...](https://wpdev.uservoice.com/forums/266908-command-prompt-console-bash-
on-ubuntu-on-windo/suggestions/16108045-opencl-cuda-gpu-support)

~~~
Eridrus
Thanks for the work you're doing, it's pretty exciting! I hope MSFT remains
committed to this project.

A) This is only a terminal, which isn't really more useful than opening a WSL
window, I want to be able to debug python easily. I don't really know how the
python debugging protocol works, so I'm not sure if stdin/out is enough, but
even if it is enough there's some glue code missing to make this trivial, I
need to have a binary that can take the same arguments as python and translate
windows paths to WSL paths. And then the Python VS code tools also have some
pretty cool Jupyter/IPython integration; I'm not sure that will just work with
an executable that pretends to be python. Would be cool if the people working
on VS code bits were thinking about WSL, rather than users having to come up
with individual hacks.

2) Cool, I assumed backlog meant "not going to happen", will be great if it
gets anywhere. Though I'm also interested in OpenGL for graphics; I wanted to
run OpenAI's gym project, but that needed OpenGL for rendering. Not
necessarily expecting you to write an X server, but would be cool if you could
cooperate with or fund a project like Xming or
[https://github.com/kpocza/LoWe](https://github.com/kpocza/LoWe) or something.

------
hakonrossebo
WSL is a great feature that could really improve the development workflow on
windows. The WSL would benefit from a blogpost with a different perspective,
describing how to do web development, mounting into Windows filesystem, -how
to setup and use tmux/vim etc.

~~~
bitcrazed
Great idea - can't wait to see your post :)

------
z3t4
Or cryptic error messages because the config file contains a "carriage
return".

------
fetbaffe
Pro tip: I use wsl-terminal with WSL

[https://github.com/goreliu/wsl-terminal](https://github.com/goreliu/wsl-
terminal)

------
SticksAndBreaks
Addition: Do not modify files which where modifyied in another OS that was
send into hibernation. A world of pain awaits you.

------
johnhenry
I ran into an issue when I first started using WSL. I was able to mitigate it
by changing the settings on my text editor to use LF line endings and ensuring
that git does not automatically modify line endings upon checkout. I have not
had any issues since.

------
freekh
Yeah... I learnt this the hard way a couple of weeks back... Sigh...

------
45h34jh53k4j
Perfectly reasonable but I do suggest that Microsoft should have made the
folder invisible to admin (need SYSTEM or higher, etc), so users were not
tempted to touch the files in that folder.

~~~
wvenable
Except that you need permissions to those files to, you know, use them in the
subsystem for Linux. The WSL, correctly and securely, runs under your user
account.

------
jasonjei
Has Windows harmonized line breaks? Or is it still \r\n rather than \n like in
the *nix world?

~~~
OliverJones
Is the Pope Hindu? Do bears use the restrooms in the Waldorf Astoria hotel?

------
eriknstr
I think what's sad about this is the users who will believe that it was a
fault of Linux that their files disappeared and as a result they will stay
with MS.

------
zouhair
This is like some bad teen movie where the bully is forced to live with the
nerd.

------
angryasian
In general these types of issues are why their implementation doesn't work for
me. I'd prefer something with more seamless integration.

When on windows I pretty much stick with git bash and windows implementations
of my dev stack.

~~~
matt_wulfeck
Microsoft is adding the ubuntu subsystem, which means this is a "problem"
that's only going to get worse before it gets better. Thankfully once it gets
better it will be a lot easier to use both systems and you won't need to keep
such rigid isolation between the systems.

------
necessity
"What should I do instead?" \- use a decent os

------
smegel
1\. DO store files in your Windows filesystem that you want to create/modify
using Windows tools AND Linux tools 2\. DO NOT create / modify Linux files
from Windows apps, tools, scripts or consoles

What bizarrely contradictory advice.

"Use Windows tools to modify files used by Linux, but don't use them to modify
Linux files".

------
quotemstr
Use Cygwin. This problem and related issues point toward reasons why: Cygwin
is _designed_ to bridge, by hook or by crook, the gap between the Win32 and
POSIX worlds. It's not perfect, but it tries to work in a mixed environment
--- even ACLs mostly work. Cygwin's Windows integration is so good that you
can call CreateWindow from a Cygwin process and have it Just Work.

The NT POSIX subsystem, on the other hand, is a very different beast. It's
more of a container or VM-like object. That kind of operation is useful for
some tasks, but when I want to use POSIX and Windows tools together on the
same task, I don't want a container. I want tight integration, which Cygwin
provides.

~~~
TazeTSchnitzel
WSL is not the NT POSIX subsystem, which was a completely different thing that
died a while ago.

~~~
quotemstr
It's not SFU either, but it's a reincarnation of the same idea. It's a
subsystem distinct from the Windows one. This year's branding is irrelevant.

~~~
xorblurb
The new approach is relevant. NT POSIX or SFU was a completely different
target from mainly used Unixes of their time. Now GNU/Linux has supplanted
everything (Mac Os does not really rely on nor is administered by its Unix
layer), Ubuntu is a major and well maintained distro, and even the WSL Beta in
the AU has a quite impressive compat -- and the last insider versions are even
better. So will WSL become irrelevant? Maybe: either at the same time Ubuntu
does, or if MS decides to stop this subsystem project. I hope they don't... :)

~~~
quotemstr
It's just a different system call interface though. The big integration
problem remains. Microsoft could definitely solve it differently:
specifically, there should be a winuser.so loadable in WSL that would do the
same job as user32.dll and kernel32.dll do in win32. It could, in principle,
talk to win32k.sys.

Personally, though, I'd like Microsoft to make two changes to the _existing_
win32 subsystem:

1) expose as public API the interface between the kernel console subsystem and
conhost.exe: this interface will not only allow Cygwin to supply a real pty
layer, but also let programs like console2 work much better

2) teach win32 userspace components to tolerate NtCreateProcess-based fork,
and make CSRSS understand what's going on. Then regular win32 processes (like
Cygwin programs) can fork and take advantage of the copy-on-write semantics
that NT _already supports_

If I ever rejoin Microsoft, I'm going to push to get this functionality
implemented. If core Windows ever goes open source, I'll implement it myself.

~~~
xorblurb
Forking and copy on write is important for historical reasons but very few
tools can take advantage of this model, and it causes its load of problems
(ex: if widely used on the system, need for overcommit). Something like
CreateProcess / posix_spawn / vfork+exec is actually a better model 99% of the
time fork would be used for fork+exec. I don't see what would be achieved in
the pure Win32 ecosystem by providing more support for forking+CoW, and Cygwin
already work well enough without that kind of official Win32 support of
fork+CoW.

I understand what you desire is to get something like a better Cygwin instead
of following the WSL approach, however that won't leverage the Ubuntu
ecosystem, so that would still have the same problems as what I described for
NT Posix and SFU: Cygwin is a target completely separated from mainstream ones
-- the tools WSL is trying to provide (and succeeds in doing so -- available
today) would not be as well maintained and/or even working correctly (if
available at all).

Now I agree that an interface is needed to provide alternate console
implementation, and the current situation in that regard, and hacks used to
make ConEmu or console2 kind of work, are terrible (and unfortunately it is
now even worse with WSL, and an absolute mess with the new WSL interop in
Insider builds)

~~~
quotemstr
Lots and lots of software _does_ use fork, though, so in lieu of rewriting the
world, fork has some utility.

> Cygwin already work well enough

:laughter_to_sobbing:

Cygwin's fork _works_ , but it has two major problems: 1) it's slow, and 2) it
relies on awful hacks to load DLLs at the same virtual offsets in parent and
child, and if these hacks fail (which they do if it's the wrong day of the
week, or if the moon has the right phase), your fork fails. With proper fork
support, this operation becomes fast and reliable.

I agree that vfork is better. Implementation complexities made Cygwin define
vfork as fork though. :-(

> I understand what you desire is to get something like a better Cygwin
> instead of following the WSL approach, however that won't leverage the
> Ubuntu ecosystem,

That's true, but Cygwin has enough critical mass that its own ecosystem is
usable. FOSS developers of third-party packages usually care to some minimal
degree about Cygwin support, for example, and will take patches to help it
work better. SFU never achieved that critical mass.

> Now I agree that an interface is needed to provide alternate console
> implementation

I never understood the difficulty of making this feature happen. It's clearly
needed, as evidenced by all the awful hacks out there, and it's not even that
_hard_ : I've seen the conhost code. You could make the protocol a public API
with minimal changes.

Yes, the resulting interface ends up being a bit more complicated than
openpty(3), but that's okay.

------
revelation
This is clearly broken. Don't be too smart for your own good and use long
abandoned features like NTFS "Extended attributes". Save the stuff you need in
a metadata file and be done with it.

------
MBCook
If this directory is special, why doesn't Windows treat it that way? Put
something in the EA that means "This file can't be read/modified by normal
programs" so people can't make the mistake in the first place.

Obviously making it so programs _can_ modify these files successfully would be
great, but that's a much bigger job.

~~~
nxc18
It is marked special. You have to go out of your way to even see it, and
Windows Explorer complains and gives you a stern warning when you do.

~~~
MBCook
As someone who hasn't used Windows in 15 years... I didn't know that. I'm glad
I got down voted to find out.

Either way, once you get to it, couldn't the filesystem APIs treat it read-
only and prevents someone from making these kind of mistakes in the first
place?

~~~
wvenable
That's a lot of exceptional cases for something you shouldn't touch. It's kind
of like saying, if I'm root and I've disabled "\--preserve-root" and then I
"rm * /", that Linux should have something else to prevent the user from
hosing their own system.

I mean they could do that, but where do you draw the line?

