bash command not work for me after edit .bashrc using ST3

[AdelDima]

Hell, I have a problem that when I type bash command I get
bash: /home/<user>/.bashrc: Input/output error , and when I open my terminal all the time I got

bash : home//.bashrc: input/output error
Note : This is happeing after I opened the .bashrc using ST3 using windows.

Thanks

[russalex]

Editing files within VolFs from a Windows program is not supported. This means it is not supported to modify files under / (only exception is DrvFs, i.e. /mnt/) from Windows.

There are a number of reasons for this. We go into more details on in our filesystem blog post and #403.

Please use a Linux / Ubuntu app to modify files these files (vim, emacs, nano, etc...). Editing these files in many Windows applications will make the file disappear from WSL. FYI: you can get into similar issues if you modify your Linux directory structure from within WIndows.

[AdelDima]

Thanks, I edit it using nano and save it again fix the problem.

[russalex]

@AdelDima, thanks for confirming. Closing this one out as a dup of #403.

[sytelus]

I ended up in same situation today but with the difference that I can't get rid of error just by editing file in Linux. Is there any way to repair this? Or should I re-install BashOnWindows? But how?

[nicktimko]

@sytelus I also got stuck; but deleting the file that I touched with Windows (that seemed to disappear inside WSL/bash) in Explorer allowed me to recreate it inside WSL.

[sytelus]

In my case, nothing got it fixed. I used following command to delete BashOnWindows and then reinstall it:

lxrun /uninstall /full

lxrun /install /y

[nicktimko]

Here is a nice whiteboard-talk about how WSL/LXSS works and why editing/copying files and moving them into the VolFS mounts won't always work. At about 15:15 in the video

VolFS pretends it's [files are] Linux and all the extra information (owner, user ID, mode bits, file type, etc.) [...] are stored within NTFS extended attributes. [...]

That's also one of the reasons why you can go here and see all your files in Windows, but if you copy a file from somewhere else into [AppData/Local/lxss] then go into Bash, you won't see it because that file doesn't have the extended attributes on it, so we don't know what to do with it. And if you, unfortunately, go into [there] and open a file with Notepad and try to edit it, because a lot of the time when you save a file, text editors create a new file and replace the old, so the new file won't have those extended attributes and it will be gone.

There are three VolFS mounts, /, /root, and /home that reflect files in AppData/Local/lxss, and for (typical?) uninstalls, supposedly only the root is blown away, so later if you want to reinstall, your user files are still there. I wonder if the /full on the uninstall command @sytelus ran blew everything away so it could be recreated. If deleting the file didn't work, maybe the folder's properties were borked?

[air]

deleting the file that I touched with Windows (that seemed to disappear inside WSL/bash) in Explorer

I also needed to start a new bash shell to pick up the fact that .bashrc had been deleted from Explorer.

[SgtPooki]

I kept getting input/output error whenever I tried to touch,vim,nano, anything the file in Bash, so I successfully fixed my problem by doing the following:

1. copy the contents of the current .bashrc using windows, and paste to any other file (tmp file in VS code)
2. deleted the file in windows (using VS code)
3. touched the file in linux touch ~/.bashrc
4. sudo vim ~/.bashrc
5. :set paste
6. i
7. paste contents of old .bashrc into new bashrc.
8. press ESC and then :wq

Good to go.

[cybexr]

same question.

[verdy-p]

Shouldn't the Linux files exposed in Windows be handled by a reparse point library, so that it knows that the file is part of an area managed by Linux, and that needs at least basic extended attributes, added automatically even if the Windows application modifying it or creating it does not create these attributes themselves (as they don't know how to map Linux attributes from/to Windows attributes).
It means that there's a missing layer in WSL: a DLL to handle the reparse point and mount the Linux filesystem specially.
Otherwise,without the reparse point, the Linux exposed files and folders should have strict read-only policies (write allowed only to the WSL layer using its own special user account under Windows; note also that there may be multiple Linux filesystems running in containers with their own local users and policies).
For now only "/mnt" on Linux allows the reverse: allowing Linux to work with Windows files under some Linux-know local policies that are mapped locally to the "remote" Windows policies. But the same kind of layer should exist in the reverse direction, by creating at least suitable extended attributes or exposing the Windows attributes to default Linux attributes (relevant to the Linux user mounting the Windows filesystem on Linux: these extended attributes don't necessarily need to be stored in NTFS, they can be synthetized virtually and this synthetic generation tuned by Linux "mount -o..." options; the synthetic Linux attibutes could also be used to avoid that WSL instantly stores NTFS attributes, when Linux programs modify the Linux filesystem, when they are not different from the default)

[therealkenc]

That's #1524.