Microsoft: don't edit Linux files in Windows
Microsoft warned all Windows 10 users who have installed the Windows Subsystem for Linux recently that they should not modify Linux files on Windows using apps, tools, scripts or other means.
The Windows Subsystem for Linux (WSL) is part of Microsoft's new Windows 10 operating system. It is not installed by default however and needs to be enabled by a user or administrator before it becomes available.
To enable Bash on Windows 10, a user would have to enable the Developer Mode first in the Settings app under Update & Security > For Developers. Once done, it is necessary to open the "Turn Windows features on or off" option in the classic Control Panel, and select Windows Subsystem for Linux to enable the feature.
Windows 10 downloads Bash then from the Store. Once that operation completes, you may fire it up by writing bash on the command prompt.
Don't edit Linux files on Windows
Microsoft warns users of Windows 10 not to edit any Linux files that are part of the Linux subsystem using Windows apps, scripts, console commands or other means.
DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.
The reason given is that creating or changing Linux files from Windows may result in data corruption or even a damaged Linux system.
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!
Microsoft refers to all Linux files that are part of WLS, and those are all stored under %localappdata%\lxss on the system drive.
The reason for this is that file metadata is handled differently on Linux than it is on Windows. Since WSL is stored in a NTFS folder, it is necessary that it "calculates and persists each Linux file's metadata in its NTFS extended attributes".
While WSL is capable of that, Windows apps, scripts, tools or programs are not. This means that create or modify events won't store any Linux file metadata.
Files without proper metadata may not open, write or read at all because of this.
Microsoft's solution is to store files that you need to use on Windows and Bash in separate directories.
When you access files on your Windows filesystem from within Bash, WSL honors the NT filesystem behaviors (e.g. case-insensitivity), permissions, etc. so you can easily access the same files using both Windows tools and Bash tools without having to copy files back and forth between filesystems.
Closing Words
While you might say that this is inconvenient if you use WSL regularly, it would be the same if you'd copy a NTFS file to a Linux partition, edit it, and copy it back.
Now You: Do you use Bash on Windows 10?
Then it is fucking worthless to me. How the fuck am I supposed to use this thing to write code if I can’t use my IDE? I shouldn’t need two fucking physical machines for this. And no, I’m not doing through /mnt. Everything is 777 and it looks ugly as piss, plus symlinks STILL don’t work.
Please do not alter this open-source file.
Hi.
The reason for “the weird character” shown is that Windows does not represent “newline” in a text file the same way as Unix, Linux, OS X or any other operating system that matters:
https://en.wikipedia.org/wiki/Newline
On those systems, newline is represented by a single “LF” (Line Feed) character, whereas on Windows, linefeed is represented by two characters CR+LF (Carriage Return + Line Feed).
The funny thing is that text editors in Linux and Unix etc do not have any problem displaying and editing text files that have the Windows “newline” format. Windows could easily do the same and recognize the single LF character newline format. But I guess Microsoft are too arrogant to do that since it is not their “standard”.
…and you may disrupt the calling home to msoft from Linux, we don’t want you looking around in there so scary-scary is a good deterrent. :)
Probably though, the End Of Line (EOL) in windows is char_10 plus Char_13 (Line Feed and Carriage Return)
Linux only has one character char_10, Line Feed.
In a crappy editor, the extra character will be carried around to the next item and compounding with every line thereafter, thus making it useless garbage to Linux.
What they “forget” to mention is that using a programmers editor you can define Linux of windows EOL. Even Notepad++ allows that.
By the way, the character at the end of the file is the standard EOF char_26 (End Of File) which may or may not exist for use in a crappy editor.
“Crappy” is a poor choice of words. CR+LF and LF are both valid choices so it boils down to personal preference.
Basically, Microsoft is trying to associate Windows Registry crap with its “Linux” (<-and I use the term loosely) subsystem (so, just a good reason to not use it at all).
Windows and Linux handle file metadata differently, hence the incompatibilities.
Deleted the whole folder as i don’t have any use for it, everything works good no issues.
I noticed text files created in Linux have this weird character at the end of the file when viewed in Windows. Same with spreadsheets. There are a lot of hassles converting between Linux and Windows b/c of incompatible file structuring.
There really shouldn’t be any problems at all with text files. Try using the free Notepad++ (https://notepad-plus-plus.org/) instead of Windows Notepad or Wordpad. It does seamless conversions between the two text formats and allows you to save the changes. There’s also the Linux utility unix2dos (not sure if that’s included with the Windows 10 Ubuntu subsystem) you can use to convert text files before they get opened in Windows.
When it comes to your spreadsheets, it all depends on which format you use. If it’s stored a plain text file, the above applies equally. If it’s something more complicated than that I’m sure there’s an easy workaround in that case, too. So which spreadsheet format are you using?
Oh this was a long time ago when I gave Linux a spin. Can’t remember exact spreadsheet format…
Hi.
The reason for “the weird character” shown is that Windows does not represent “newline” in a text file the same way as Unix, Linux, OS X or any other operating system that matters:
https://en.wikipedia.org/wiki/Newline
On those systems, newline is represented by a single “LF” (Line Feed) character, whereas on Windows, linefeed is represented by two characters CR+LF (Carriage Return + Line Feed).
The funny thing is that text editors in Linux and Unix etc do not have any problem displaying and editing text files that have the Windows “newline” format. Windows could easily do the same and recognize the single LF character newline format. But I guess Microsoft are too arrogant to do that since it is not their “standard”.
They’ve embraced it, extended it, and what do you expect Microsoft to do with Linux now?