can't delete file from Ubuntu subsystem on Windows 10 Enterprise

Question

This probably is the wrong forum, but I'll give it a go anyway. I'm running the ubuntu subsystem in Windows 10 Enterprise:

root@hostname:/directory/stuff# cat /etc/*release
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=20.04
DISTRIB_CODENAME=focal
DISTRIB_DESCRIPTION="Ubuntu 20.04.3 LTS"

The file is in a repo and shows up with ls and git status, but not in the GUI ("Hidden Files" is checked in explorer view options) or with dir in cmd. It's a "hidden" file that shows up when you open an Excel spreadsheet - only the spreadsheet is closed. Even if I open and close again, it's not removable. I can modify ownership and permissions with chmod and chown, which is weird that I can't do anything else:

root@hostname:/directory/stuff# ll
total 14600
...
-rwxrwxrwx 0 my_name my_name     165 Feb 14 13:25 '~$Copy of Full Compilation of Databases for Audit.xlsx'*
root@hostname:/directory/stuff# chown root: ~\$Copy\ of\ Full\ Compilation\ of\ Databases\ for\ Audit.xlsx 
root@hostname:/directory/stuff# ll
total 14600
...
-rwxrwxrwx 0 root    root        165 Feb 14 13:25 '~$Copy of Full Compilation of Databases for Audit.xlsx'*

I've tried:

root@hostname:/directory/stuff# ls -i
...
1688849860795414 '~$Copy of Full Compilation of Databases for Audit.xlsx'
....
root@hostname:/directory/stuff# find . -inum 1688849860795414 -exec rm {} \;
rm: cannot remove './~$Copy of Full Compilation of Databases for Audit.xlsx': No such file or directory
....
root@hostname:/directory/stuff# rm -i -- ./*
...
rm: remove regular file './~$Copy of Full Compilation of Databases for Audit.xlsx'? y
rm: cannot remove './~$Copy of Full Compilation of Databases for Audit.xlsx': No such file or directory
....
root@hostname:/directory/stuff# ls -1b
...
~$Copy\ of\ Full\ Compilation\ of\ Databases\ for\ Audit.xlsx
root@hostname:/directory/stuff# rm ~$Copy\ of\ Full\ Compilation\ of\ Databases\ for\ Audit.xlsx
rm: cannot remove '~ of Full Compilation of Databases for Audit.xlsx': No such file or directory
....
root@hostname:/directory/stuff# mv ~\$Copy\ of\ Full\ Compilation\ of\ Databases\ for\ Audit.xlsx just_a_file.xlsx
mv: cannot move '~$Copy of Full Compilation of Databases for Audit.xlsx' to 'just_a_file.xlsx': No such file or directory

Anything that anyone can add to this would be great!!

Correction: Above, I said I couldn't see the file from CMD with dir, but I can with dir /a -- so windows sees it on some level. However, I still can't remove it, even from CMD (What's weird is that it does tab-complete here).

C:\Users\me\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\rootfs\directory\stuff>dir /a
 Volume in drive C has no label.
...
2022-02-14  13:25               165 ~$Copy of Full Compilation of Databases for Audit.xlsx
...

C:\Users\me\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\rootfs\directory\stuff>del "~$Copy of Full Compilation of Databases for Audit.xlsx"
Could Not Find C:\Users\me\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\rootfs\directory\stuff\~$Copy of Full Compilation of Databases for Audit.xlsx

Answer 1

It's very likely you have some sort of WSL filesystem corruption. I wouldn't jump to that conclusion so quickly, but:

• It's apparent that you are using WSL version 1, since you can see the rootfs directory from CMD. That's not possible in WSL2, since it stores its filesystem in a virtual disk (ext4.vhdx) which isn't accessible from CMD.

• You are accessing the rootfs directory from Windows applications (such as CMD). If you are doing that in an attempt to delete that file, I'm worried that you used that same path to create or edit a file from Excel.

• Accessing that directory is known to cause WSL filesystem corruption. To quote from that page:

  DO NOT, under ANY circumstances, access, create, and/or modify Linux files inside of your %LOCALAPPDATA% folder using Windows apps, tools, scripts, consoles, etc.

  Opening files using some Windows tools may read-lock the opened files and/or folders, preventing updates to file contents and/or metadata, essentially resulting in corrupted files/folders.

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

That sounds like what you are experiencing.

(Side-note, although it's not applicable in your case: It's more accurate to say "Don't access ... Linux files in rootfs", regardless of the location, since you can have WSL1 instances placed outside of AppData.)

If at any point, you accessed that path using Excel, Git for Windows, or any other Windows tool, it could easily have resulted in the lock that you are seeing.

Note that WSL2's filesystem is much more robust, if your use-case (and computer) supports using WSL2.

Note also that, as that Microsoft blog mentions, you can access WSL files from Windows. It's just that you need to use the \\wsl$\<distroname> path in order to do so safely.

---

For the "suggested solution", I'm going to copy/paste from an answer to a similar problem that I provided on Ask Ubuntu a few days ago, although I never heard back from that poster on whether or not they were successful in recovering using these instructions:

Potential solution:

I'm assuming you've restarted your PC, but if not, try it just in case to make sure any handles/locks are released. It has a relatively small chance of working, but it's worth a shot.

If that doesn't work, I'd recommend the following for attempting to repair the WSL1 instance.

Basically round-trip the WSL1 instance through a wsl --export/wsl --import. The tar round-trip that this process performs may (hopefully) remove the corrupted file (or at least the lock) when archiving or unarchiving, one or the other.

From PowerShell:

# Confirm the distribution name
wsl -l -v
# Distribution name may be "Ubuntu" or "Ubuntu-20.04" - Adjust the following lines accordingly:
wsl --shutdown
cd ~\Documents
mkdir WSL\images
mkdir WSL\instances\UbuntuRecovery
wsl --export Ubuntu WSL\images\ubuntu.tar
wsl --import UbuntuRecovery WSL\instances\UbuntuRecovery WSL\images\ubuntu.tar --version 1
wsl -d UbuntuRecovery

See if the file is gone or deletable in that new instance.

If so, and if everything else looks okay in the new instance, then:

• Set the default username in that instance via a /etc/wsl.conf file per this answer.
• Exit the instance
• Again, from PowerShell:

  wsl --terminate UbuntuRecovery
  wsl --set-default UbuntuRecovery
  

The new instance will be the default whenever wsl is run.

Finally, remove the original corrupted instance with:

wsl --unregister Ubuntu

Important: This is a destructive operation. Make sure that everything is working as intended. On the bright side, we've made a backup already ...

You can also uninstall the Ubuntu "App" that was installed from the Store at that point.

You'll launch via wsl (if you haven't been already) or Windows Terminal since the ubuntu.exe (or ubuntu2004.exe) command will be gone.

Answer 2

I'm not sure which stars aligned, but I was able to remove the file this morning. It could have been the fact that I shut down the computer to take it home and the lock cleared, but I don't know if I'll ever know for sure. To get it to delete, I simply pulled the repo into a proper Linux environment - Linux Mint running on a VM on the same machine - not that it had to be a VM - or on the same windows computer with the issue, but it is, so there you go. Because it was a proper Linux environment I was able to delete it in nemo. I could have swore this particular file didn't pull down when I synced yesterday, but it did today and I removed the little bugger. When I committed and pushed, then pulled on the Ubuntu subsystem on the Windows machine, the file was removed:

 dir/to/file > master > git pull
   01239e91..452981f2  master     -> origin/master
Updating 01239e91..452981f2
Fast-forward
 dir/to/file/All-Production.vsdx                                    | Bin 1101177 -> 1100811 bytes
 dir/to/file/~$Copy of Full Compilation of Databases for Audit.xlsx | Bin 0 -> 165 bytes
 2 files changed, 0 insertions(+), 0 deletions(-)
 create mode 100755 dir/to/file/~$Copy of Full Compilation of Databases for Audit.xlsx
..
### I deleted file in GIU (nemo) at this point ###
..
 dir/to/file > master > git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
    deleted:    ~$Copy of Full Compilation of Databases for Audit.xlsx
..
 dir/to/file > master > git rm \~\$Copy\ of\ Full\ Compilation\ of\ Databases\ for\ Audit.xlsx
rm 'dir/to/file/~$Copy of Full Compilation of Databases for Audit.xlsx'
 dir/to/file > master > git commit -a -m "fixing stupborn ghost "                                         
[master b543cc14] fixing stupborn ghost
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100755 dir/to/file/~$Copy of Full Compilation of Databases for Audit.xlsx
 dir/to/file > master > git push                                 
Enumerating objects: 9, done.
Counting objects: 100% (9/9), done.
Delta compression using up to 6 threads
Compressing objects: 100% (5/5), done.
Writing objects: 100% (5/5), 425 bytes | 425.00 KiB/s, done.
Total 5 (delta 4), reused 0 (delta 0)
remote: Resolving deltas: 100% (4/4), completed with 4 local objects.
To github.com:my/repo.git
   452981f2..b543cc14  master -> master
....
me@wind_mach directory $ git pull
Enter passphrase for key '/home/me/.ssh/id_rsa':
...
   452981f2..b543cc14  master     -> origin/master
Updating 452981f2..b543cc14
Fast-forward
 dir/to/file/~$Copy of Full Compilation of Databases for Audit.xlsx | Bin 165 -> 0 bytes
 1 file changed, 0 insertions(+), 0 deletions(-)
 delete mode 100755 Dir/to/file/~$Copy of Full Compilation of Databases for Audit.xlsx

So there you have it.