I edited a Linux file with a Windows program while using the Windows Subsystem for Linux, and now I can't...

Where can/should I, as a high schooler, publish a paper regarding the derivation of a formula?

Tex Quotes(UVa 272)

How do you interpolate outside the range of data?

Why doesn't the Bitcoin-qt client ask for the Wallet passphrase upon startup?

How do I, an introvert, communicate to my friend and only colleague, an extrovert, that I want to spend my scheduled breaks without them?

Papers on arXiv solving the same problem at the same time

Is gzip atomic?

Heyacrazy: No Diagonals

How do the Etherealness and Banishment spells interact?

If two Lore Bards used the Cutting Words feature on an ability check or attack, would they stack?

Did a flight controller ever answer Flight with a no-go?

Algorithms vs LP or MIP

Transposing from C to Cm?

Asymmetric table

Are there any elected officials in the U.S. who are not legislators, judges, or constitutional officers?

What should come first—characters or plot?

How to know which loss function is suitable for image classification?

Why is the UK so keen to remove the "backstop" when their leadership seems to think that no border will be needed in Northern Ireland?

Why is there a difference between predicting on Validation set and Test set?

How do proponents of Sola Scriptura address the ministry of those Apostles who authored no parts of Scripture?

Architectural feasibility of a tiered circular stone keep

How to respectfully refuse to assist co-workers with IT issues?

If someone uses the Command spell and says "drop", what happens?

Obtaining the intermediate solutions in AMPL



I edited a Linux file with a Windows program while using the Windows Subsystem for Linux, and now I can't access it any more


How am I supposed to use Bash on Ubuntu on Windows environment?Permission denied when trying to 'mv' a directoryHow can I access UNC paths using the Windows Subsystem for Linux?Access a physical Ext3 drive under Windows host system for defrag?Not able to access Docker after installation on Windows Subsystem for LinuxOpen file behavior using Ranger in Windows Subsystem for LinuxUsing cp to copy ~/.config to an external drive but getting “cannot create regular file…File exists” errors






.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ margin-bottom:0;
}







11















I'm using Bash on Ubuntu on Windows or another Linux distribution within the Windows Subsystem for Linux and I've edited a Linux file inside the lxss directory with a Windows editor.



Now whenever I or a program try to access it from Linux, I get an error "input/output error", or the file just disappears completely even though I can see it's definitely there in File Explorer.



cat abc
cat: abc: Input/output error


Why has this happened? What can I do to fix it? How can I avoid it in future?










share|improve this question

























  • In my case, I just ran sudo chmod -R 777 filename and it worked.

    – MathuSum Mut
    Jun 12 at 7:57


















11















I'm using Bash on Ubuntu on Windows or another Linux distribution within the Windows Subsystem for Linux and I've edited a Linux file inside the lxss directory with a Windows editor.



Now whenever I or a program try to access it from Linux, I get an error "input/output error", or the file just disappears completely even though I can see it's definitely there in File Explorer.



cat abc
cat: abc: Input/output error


Why has this happened? What can I do to fix it? How can I avoid it in future?










share|improve this question

























  • In my case, I just ran sudo chmod -R 777 filename and it worked.

    – MathuSum Mut
    Jun 12 at 7:57














11












11








11


5






I'm using Bash on Ubuntu on Windows or another Linux distribution within the Windows Subsystem for Linux and I've edited a Linux file inside the lxss directory with a Windows editor.



Now whenever I or a program try to access it from Linux, I get an error "input/output error", or the file just disappears completely even though I can see it's definitely there in File Explorer.



cat abc
cat: abc: Input/output error


Why has this happened? What can I do to fix it? How can I avoid it in future?










share|improve this question














I'm using Bash on Ubuntu on Windows or another Linux distribution within the Windows Subsystem for Linux and I've edited a Linux file inside the lxss directory with a Windows editor.



Now whenever I or a program try to access it from Linux, I get an error "input/output error", or the file just disappears completely even though I can see it's definitely there in File Explorer.



cat abc
cat: abc: Input/output error


Why has this happened? What can I do to fix it? How can I avoid it in future?







windows-subsystem-for-linux






share|improve this question













share|improve this question











share|improve this question




share|improve this question










asked Dec 2 '16 at 20:51









Michael HomerMichael Homer

54.9k9 gold badges154 silver badges188 bronze badges




54.9k9 gold badges154 silver badges188 bronze badges
















  • In my case, I just ran sudo chmod -R 777 filename and it worked.

    – MathuSum Mut
    Jun 12 at 7:57



















  • In my case, I just ran sudo chmod -R 777 filename and it worked.

    – MathuSum Mut
    Jun 12 at 7:57

















In my case, I just ran sudo chmod -R 777 filename and it worked.

– MathuSum Mut
Jun 12 at 7:57





In my case, I just ran sudo chmod -R 777 filename and it worked.

– MathuSum Mut
Jun 12 at 7:57










1 Answer
1






active

oldest

votes


















12















Why has this happened?



Because conventional Unix filesystems work differently than Windows filesystems, WSL stores extra information about Linux-specific properties of files in the extended attributes of the Windows files used to represent them. Ordinary Windows programs don't know about these attributes and won't preserve them when you edit the file. Important information about the file is lost when that happens.



When WSL tries to read a file, and it can't find the attributes it expects, an error is reported, just like what would happen if a native filesystem were corrupted. If it never sees the attributes on a file in the first place, that file is just treated as non-existent and won't show up in file listings.



The official WSL advice is




DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.



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!




for this reason (but bigger, and redder, and with more underlines). "Linux files" means anything inside your lxss directory. You can modify regular Windows files from inside Linux through the /mnt/c/... DrvFS filesystem, but not the reverse.



However, the 1903 Windows 10 release introduces a new mechanism that does allow files to be edited safely from Windows as long as you go about it the right way. That doesn't help to fix the problem of already-corrupted files, but it can avoid it in future.



What can I do to fix it?



If you've already edited a file and now you can't access it, it's still possible to read the contents from Windows itself and to restore the file that way.



To do that, you'll need to:




  1. Navigate back into the location within the AppDataLocallxss directory that the file is in using File Explorer and move the file out to somewhere else on your drive, like your desktop.

  2. Restart WSL after that to clear its internal cache, which you can do just by closing all your terminals and opening a new one. If you have background server processes running, you will also need to stop those.

  3. Within Linux again, go to the original location of the corrupted file. It won't show up at all now if you've successfully moved the file out of the way. Run ls to check.


  4. Check the file you moved out: run



    cat /mnt/c/Users/.../Desktop/abc


    to see the original contents of the file.




  5. If everything's worked so far, you can now copy that file back into the place you expected it to be:



    cp /mnt/c/Users/.../Desktop/abc ~/alphabet/abc


    The cp command will cause WSL to restore the necessary hidden attributes on the file.




These instructions will work for regular data files, but if it's an important operating system file, you may need to reinstall entirely. For many non-critical programs, deleting the corrupted file from Windows and reinstalling the program using the package manager will be sufficient. You won't be able to delete the file from inside Linux once it's been corrupted.



How can I avoid this in future?



Never manipulate any files within the lxss directory from Windows. Instead:




  • If you have a file you want to access from both Windows and Linux, store it outside the lxss directory, anywhere else on your Windows system. You can open Windows files from Linux using the automatic DrvFS interoperability: the /mnt/c directory contains all of the files from your C: drive, and they can be read and written from Linux.



  • Starting in the 1903 Windows release (March 2019), WSL includes a special file server that makes your files available to all Windows applications. If you run



    explorer.exe .


    then File Explorer will open up showing the current Linux directory - you can copy files in or out of that window, or edit them with any application. The directory path will be something like \wsl$Ubuntuvarwww: the \wsl$ part sends file access through an alternative, safe, path.



    If you're able, this will be the best path forward (or sometimes the point above). For older releases, read on.




  • If there's a file you need to be in a specific place, like a configuration file, and you want to edit it from Windows, you can make a symbolic link from inside Linux to the file or directory's real location:



    ln -s /mnt/c/.../abc ~/.config/xyz/abc


    This will work as long as the file doesn't need to have any specific permissions or attributes in Linux (as an executable or an SSH key would).



  • Alternatively, and perhaps better, edit your Linux files using a Linux editor within the terminal. nano, vim, and emacs are all readily available and work well under WSL, though they all have their quirks.


  • If you must edit a file with a Windows program, you don't have a recent-enough Windows version, and you can't make it a symlink, make a copy elsewhere to edit and copy it back in from /mnt/c afterwards, just like the fix above, or use version control to synchronise your edits across multiple locations.



From some experimentation, ordinary Notepad does seem to preserve the necessary attributes, but it doesn't understand Unix line endings so you're likely to corrupt the contents yourself, and I wouldn't rely on that behaviour in any case. Because this is an explicitly unsupported and undocumented operation it's unlikely that any Windows-based editor will be reliable.






share|improve this answer






























    Your Answer








    StackExchange.ready(function() {
    var channelOptions = {
    tags: "".split(" "),
    id: "106"
    };
    initTagRenderer("".split(" "), "".split(" "), channelOptions);

    StackExchange.using("externalEditor", function() {
    // Have to fire editor after snippets, if snippets enabled
    if (StackExchange.settings.snippets.snippetsEnabled) {
    StackExchange.using("snippets", function() {
    createEditor();
    });
    }
    else {
    createEditor();
    }
    });

    function createEditor() {
    StackExchange.prepareEditor({
    heartbeatType: 'answer',
    autoActivateHeartbeat: false,
    convertImagesToLinks: false,
    noModals: true,
    showLowRepImageUploadWarning: true,
    reputationToPostImages: null,
    bindNavPrevention: true,
    postfix: "",
    imageUploader: {
    brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
    contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
    allowUrls: true
    },
    onDemand: true,
    discardSelector: ".discard-answer"
    ,immediatelyShowMarkdownHelp:true
    });


    }
    });














    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f327658%2fi-edited-a-linux-file-with-a-windows-program-while-using-the-windows-subsystem-f%23new-answer', 'question_page');
    }
    );

    Post as a guest















    Required, but never shown

























    1 Answer
    1






    active

    oldest

    votes








    1 Answer
    1






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    12















    Why has this happened?



    Because conventional Unix filesystems work differently than Windows filesystems, WSL stores extra information about Linux-specific properties of files in the extended attributes of the Windows files used to represent them. Ordinary Windows programs don't know about these attributes and won't preserve them when you edit the file. Important information about the file is lost when that happens.



    When WSL tries to read a file, and it can't find the attributes it expects, an error is reported, just like what would happen if a native filesystem were corrupted. If it never sees the attributes on a file in the first place, that file is just treated as non-existent and won't show up in file listings.



    The official WSL advice is




    DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.



    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!




    for this reason (but bigger, and redder, and with more underlines). "Linux files" means anything inside your lxss directory. You can modify regular Windows files from inside Linux through the /mnt/c/... DrvFS filesystem, but not the reverse.



    However, the 1903 Windows 10 release introduces a new mechanism that does allow files to be edited safely from Windows as long as you go about it the right way. That doesn't help to fix the problem of already-corrupted files, but it can avoid it in future.



    What can I do to fix it?



    If you've already edited a file and now you can't access it, it's still possible to read the contents from Windows itself and to restore the file that way.



    To do that, you'll need to:




    1. Navigate back into the location within the AppDataLocallxss directory that the file is in using File Explorer and move the file out to somewhere else on your drive, like your desktop.

    2. Restart WSL after that to clear its internal cache, which you can do just by closing all your terminals and opening a new one. If you have background server processes running, you will also need to stop those.

    3. Within Linux again, go to the original location of the corrupted file. It won't show up at all now if you've successfully moved the file out of the way. Run ls to check.


    4. Check the file you moved out: run



      cat /mnt/c/Users/.../Desktop/abc


      to see the original contents of the file.




    5. If everything's worked so far, you can now copy that file back into the place you expected it to be:



      cp /mnt/c/Users/.../Desktop/abc ~/alphabet/abc


      The cp command will cause WSL to restore the necessary hidden attributes on the file.




    These instructions will work for regular data files, but if it's an important operating system file, you may need to reinstall entirely. For many non-critical programs, deleting the corrupted file from Windows and reinstalling the program using the package manager will be sufficient. You won't be able to delete the file from inside Linux once it's been corrupted.



    How can I avoid this in future?



    Never manipulate any files within the lxss directory from Windows. Instead:




    • If you have a file you want to access from both Windows and Linux, store it outside the lxss directory, anywhere else on your Windows system. You can open Windows files from Linux using the automatic DrvFS interoperability: the /mnt/c directory contains all of the files from your C: drive, and they can be read and written from Linux.



    • Starting in the 1903 Windows release (March 2019), WSL includes a special file server that makes your files available to all Windows applications. If you run



      explorer.exe .


      then File Explorer will open up showing the current Linux directory - you can copy files in or out of that window, or edit them with any application. The directory path will be something like \wsl$Ubuntuvarwww: the \wsl$ part sends file access through an alternative, safe, path.



      If you're able, this will be the best path forward (or sometimes the point above). For older releases, read on.




    • If there's a file you need to be in a specific place, like a configuration file, and you want to edit it from Windows, you can make a symbolic link from inside Linux to the file or directory's real location:



      ln -s /mnt/c/.../abc ~/.config/xyz/abc


      This will work as long as the file doesn't need to have any specific permissions or attributes in Linux (as an executable or an SSH key would).



    • Alternatively, and perhaps better, edit your Linux files using a Linux editor within the terminal. nano, vim, and emacs are all readily available and work well under WSL, though they all have their quirks.


    • If you must edit a file with a Windows program, you don't have a recent-enough Windows version, and you can't make it a symlink, make a copy elsewhere to edit and copy it back in from /mnt/c afterwards, just like the fix above, or use version control to synchronise your edits across multiple locations.



    From some experimentation, ordinary Notepad does seem to preserve the necessary attributes, but it doesn't understand Unix line endings so you're likely to corrupt the contents yourself, and I wouldn't rely on that behaviour in any case. Because this is an explicitly unsupported and undocumented operation it's unlikely that any Windows-based editor will be reliable.






    share|improve this answer
































      12















      Why has this happened?



      Because conventional Unix filesystems work differently than Windows filesystems, WSL stores extra information about Linux-specific properties of files in the extended attributes of the Windows files used to represent them. Ordinary Windows programs don't know about these attributes and won't preserve them when you edit the file. Important information about the file is lost when that happens.



      When WSL tries to read a file, and it can't find the attributes it expects, an error is reported, just like what would happen if a native filesystem were corrupted. If it never sees the attributes on a file in the first place, that file is just treated as non-existent and won't show up in file listings.



      The official WSL advice is




      DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.



      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!




      for this reason (but bigger, and redder, and with more underlines). "Linux files" means anything inside your lxss directory. You can modify regular Windows files from inside Linux through the /mnt/c/... DrvFS filesystem, but not the reverse.



      However, the 1903 Windows 10 release introduces a new mechanism that does allow files to be edited safely from Windows as long as you go about it the right way. That doesn't help to fix the problem of already-corrupted files, but it can avoid it in future.



      What can I do to fix it?



      If you've already edited a file and now you can't access it, it's still possible to read the contents from Windows itself and to restore the file that way.



      To do that, you'll need to:




      1. Navigate back into the location within the AppDataLocallxss directory that the file is in using File Explorer and move the file out to somewhere else on your drive, like your desktop.

      2. Restart WSL after that to clear its internal cache, which you can do just by closing all your terminals and opening a new one. If you have background server processes running, you will also need to stop those.

      3. Within Linux again, go to the original location of the corrupted file. It won't show up at all now if you've successfully moved the file out of the way. Run ls to check.


      4. Check the file you moved out: run



        cat /mnt/c/Users/.../Desktop/abc


        to see the original contents of the file.




      5. If everything's worked so far, you can now copy that file back into the place you expected it to be:



        cp /mnt/c/Users/.../Desktop/abc ~/alphabet/abc


        The cp command will cause WSL to restore the necessary hidden attributes on the file.




      These instructions will work for regular data files, but if it's an important operating system file, you may need to reinstall entirely. For many non-critical programs, deleting the corrupted file from Windows and reinstalling the program using the package manager will be sufficient. You won't be able to delete the file from inside Linux once it's been corrupted.



      How can I avoid this in future?



      Never manipulate any files within the lxss directory from Windows. Instead:




      • If you have a file you want to access from both Windows and Linux, store it outside the lxss directory, anywhere else on your Windows system. You can open Windows files from Linux using the automatic DrvFS interoperability: the /mnt/c directory contains all of the files from your C: drive, and they can be read and written from Linux.



      • Starting in the 1903 Windows release (March 2019), WSL includes a special file server that makes your files available to all Windows applications. If you run



        explorer.exe .


        then File Explorer will open up showing the current Linux directory - you can copy files in or out of that window, or edit them with any application. The directory path will be something like \wsl$Ubuntuvarwww: the \wsl$ part sends file access through an alternative, safe, path.



        If you're able, this will be the best path forward (or sometimes the point above). For older releases, read on.




      • If there's a file you need to be in a specific place, like a configuration file, and you want to edit it from Windows, you can make a symbolic link from inside Linux to the file or directory's real location:



        ln -s /mnt/c/.../abc ~/.config/xyz/abc


        This will work as long as the file doesn't need to have any specific permissions or attributes in Linux (as an executable or an SSH key would).



      • Alternatively, and perhaps better, edit your Linux files using a Linux editor within the terminal. nano, vim, and emacs are all readily available and work well under WSL, though they all have their quirks.


      • If you must edit a file with a Windows program, you don't have a recent-enough Windows version, and you can't make it a symlink, make a copy elsewhere to edit and copy it back in from /mnt/c afterwards, just like the fix above, or use version control to synchronise your edits across multiple locations.



      From some experimentation, ordinary Notepad does seem to preserve the necessary attributes, but it doesn't understand Unix line endings so you're likely to corrupt the contents yourself, and I wouldn't rely on that behaviour in any case. Because this is an explicitly unsupported and undocumented operation it's unlikely that any Windows-based editor will be reliable.






      share|improve this answer






























        12














        12










        12









        Why has this happened?



        Because conventional Unix filesystems work differently than Windows filesystems, WSL stores extra information about Linux-specific properties of files in the extended attributes of the Windows files used to represent them. Ordinary Windows programs don't know about these attributes and won't preserve them when you edit the file. Important information about the file is lost when that happens.



        When WSL tries to read a file, and it can't find the attributes it expects, an error is reported, just like what would happen if a native filesystem were corrupted. If it never sees the attributes on a file in the first place, that file is just treated as non-existent and won't show up in file listings.



        The official WSL advice is




        DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.



        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!




        for this reason (but bigger, and redder, and with more underlines). "Linux files" means anything inside your lxss directory. You can modify regular Windows files from inside Linux through the /mnt/c/... DrvFS filesystem, but not the reverse.



        However, the 1903 Windows 10 release introduces a new mechanism that does allow files to be edited safely from Windows as long as you go about it the right way. That doesn't help to fix the problem of already-corrupted files, but it can avoid it in future.



        What can I do to fix it?



        If you've already edited a file and now you can't access it, it's still possible to read the contents from Windows itself and to restore the file that way.



        To do that, you'll need to:




        1. Navigate back into the location within the AppDataLocallxss directory that the file is in using File Explorer and move the file out to somewhere else on your drive, like your desktop.

        2. Restart WSL after that to clear its internal cache, which you can do just by closing all your terminals and opening a new one. If you have background server processes running, you will also need to stop those.

        3. Within Linux again, go to the original location of the corrupted file. It won't show up at all now if you've successfully moved the file out of the way. Run ls to check.


        4. Check the file you moved out: run



          cat /mnt/c/Users/.../Desktop/abc


          to see the original contents of the file.




        5. If everything's worked so far, you can now copy that file back into the place you expected it to be:



          cp /mnt/c/Users/.../Desktop/abc ~/alphabet/abc


          The cp command will cause WSL to restore the necessary hidden attributes on the file.




        These instructions will work for regular data files, but if it's an important operating system file, you may need to reinstall entirely. For many non-critical programs, deleting the corrupted file from Windows and reinstalling the program using the package manager will be sufficient. You won't be able to delete the file from inside Linux once it's been corrupted.



        How can I avoid this in future?



        Never manipulate any files within the lxss directory from Windows. Instead:




        • If you have a file you want to access from both Windows and Linux, store it outside the lxss directory, anywhere else on your Windows system. You can open Windows files from Linux using the automatic DrvFS interoperability: the /mnt/c directory contains all of the files from your C: drive, and they can be read and written from Linux.



        • Starting in the 1903 Windows release (March 2019), WSL includes a special file server that makes your files available to all Windows applications. If you run



          explorer.exe .


          then File Explorer will open up showing the current Linux directory - you can copy files in or out of that window, or edit them with any application. The directory path will be something like \wsl$Ubuntuvarwww: the \wsl$ part sends file access through an alternative, safe, path.



          If you're able, this will be the best path forward (or sometimes the point above). For older releases, read on.




        • If there's a file you need to be in a specific place, like a configuration file, and you want to edit it from Windows, you can make a symbolic link from inside Linux to the file or directory's real location:



          ln -s /mnt/c/.../abc ~/.config/xyz/abc


          This will work as long as the file doesn't need to have any specific permissions or attributes in Linux (as an executable or an SSH key would).



        • Alternatively, and perhaps better, edit your Linux files using a Linux editor within the terminal. nano, vim, and emacs are all readily available and work well under WSL, though they all have their quirks.


        • If you must edit a file with a Windows program, you don't have a recent-enough Windows version, and you can't make it a symlink, make a copy elsewhere to edit and copy it back in from /mnt/c afterwards, just like the fix above, or use version control to synchronise your edits across multiple locations.



        From some experimentation, ordinary Notepad does seem to preserve the necessary attributes, but it doesn't understand Unix line endings so you're likely to corrupt the contents yourself, and I wouldn't rely on that behaviour in any case. Because this is an explicitly unsupported and undocumented operation it's unlikely that any Windows-based editor will be reliable.






        share|improve this answer















        Why has this happened?



        Because conventional Unix filesystems work differently than Windows filesystems, WSL stores extra information about Linux-specific properties of files in the extended attributes of the Windows files used to represent them. Ordinary Windows programs don't know about these attributes and won't preserve them when you edit the file. Important information about the file is lost when that happens.



        When WSL tries to read a file, and it can't find the attributes it expects, an error is reported, just like what would happen if a native filesystem were corrupted. If it never sees the attributes on a file in the first place, that file is just treated as non-existent and won't show up in file listings.



        The official WSL advice is




        DO NOT, under ANY circumstances, create and/or modify Linux files using Windows apps, tools, scripts, consoles, etc.



        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!




        for this reason (but bigger, and redder, and with more underlines). "Linux files" means anything inside your lxss directory. You can modify regular Windows files from inside Linux through the /mnt/c/... DrvFS filesystem, but not the reverse.



        However, the 1903 Windows 10 release introduces a new mechanism that does allow files to be edited safely from Windows as long as you go about it the right way. That doesn't help to fix the problem of already-corrupted files, but it can avoid it in future.



        What can I do to fix it?



        If you've already edited a file and now you can't access it, it's still possible to read the contents from Windows itself and to restore the file that way.



        To do that, you'll need to:




        1. Navigate back into the location within the AppDataLocallxss directory that the file is in using File Explorer and move the file out to somewhere else on your drive, like your desktop.

        2. Restart WSL after that to clear its internal cache, which you can do just by closing all your terminals and opening a new one. If you have background server processes running, you will also need to stop those.

        3. Within Linux again, go to the original location of the corrupted file. It won't show up at all now if you've successfully moved the file out of the way. Run ls to check.


        4. Check the file you moved out: run



          cat /mnt/c/Users/.../Desktop/abc


          to see the original contents of the file.




        5. If everything's worked so far, you can now copy that file back into the place you expected it to be:



          cp /mnt/c/Users/.../Desktop/abc ~/alphabet/abc


          The cp command will cause WSL to restore the necessary hidden attributes on the file.




        These instructions will work for regular data files, but if it's an important operating system file, you may need to reinstall entirely. For many non-critical programs, deleting the corrupted file from Windows and reinstalling the program using the package manager will be sufficient. You won't be able to delete the file from inside Linux once it's been corrupted.



        How can I avoid this in future?



        Never manipulate any files within the lxss directory from Windows. Instead:




        • If you have a file you want to access from both Windows and Linux, store it outside the lxss directory, anywhere else on your Windows system. You can open Windows files from Linux using the automatic DrvFS interoperability: the /mnt/c directory contains all of the files from your C: drive, and they can be read and written from Linux.



        • Starting in the 1903 Windows release (March 2019), WSL includes a special file server that makes your files available to all Windows applications. If you run



          explorer.exe .


          then File Explorer will open up showing the current Linux directory - you can copy files in or out of that window, or edit them with any application. The directory path will be something like \wsl$Ubuntuvarwww: the \wsl$ part sends file access through an alternative, safe, path.



          If you're able, this will be the best path forward (or sometimes the point above). For older releases, read on.




        • If there's a file you need to be in a specific place, like a configuration file, and you want to edit it from Windows, you can make a symbolic link from inside Linux to the file or directory's real location:



          ln -s /mnt/c/.../abc ~/.config/xyz/abc


          This will work as long as the file doesn't need to have any specific permissions or attributes in Linux (as an executable or an SSH key would).



        • Alternatively, and perhaps better, edit your Linux files using a Linux editor within the terminal. nano, vim, and emacs are all readily available and work well under WSL, though they all have their quirks.


        • If you must edit a file with a Windows program, you don't have a recent-enough Windows version, and you can't make it a symlink, make a copy elsewhere to edit and copy it back in from /mnt/c afterwards, just like the fix above, or use version control to synchronise your edits across multiple locations.



        From some experimentation, ordinary Notepad does seem to preserve the necessary attributes, but it doesn't understand Unix line endings so you're likely to corrupt the contents yourself, and I wouldn't rely on that behaviour in any case. Because this is an explicitly unsupported and undocumented operation it's unlikely that any Windows-based editor will be reliable.







        share|improve this answer














        share|improve this answer



        share|improve this answer








        edited yesterday

























        answered Dec 2 '16 at 20:51









        Michael HomerMichael Homer

        54.9k9 gold badges154 silver badges188 bronze badges




        54.9k9 gold badges154 silver badges188 bronze badges

































            draft saved

            draft discarded




















































            Thanks for contributing an answer to Unix & Linux Stack Exchange!


            • Please be sure to answer the question. Provide details and share your research!

            But avoid



            • Asking for help, clarification, or responding to other answers.

            • Making statements based on opinion; back them up with references or personal experience.


            To learn more, see our tips on writing great answers.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f327658%2fi-edited-a-linux-file-with-a-windows-program-while-using-the-windows-subsystem-f%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown





















































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown

































            Required, but never shown














            Required, but never shown












            Required, but never shown







            Required, but never shown







            Popular posts from this blog

            Taj Mahal Inhaltsverzeichnis Aufbau | Geschichte | 350-Jahr-Feier | Heutige Bedeutung | Siehe auch |...

            Baia Sprie Cuprins Etimologie | Istorie | Demografie | Politică și administrație | Arii naturale...

            Nicolae Petrescu-Găină Cuprins Biografie | Opera | In memoriam | Varia | Controverse, incertitudini...