Modification of folder opened with code from bash produces errors

[rtlayzell]

Build [10.0.15063]

I'm not quite sure who is at fault here but I seem to be having some issues modifying a directory once it has been opened in vs-code from the bash terminal.

I first discovered this while attempting to use git-subtree; steps to reproduce.

Prerequisites:
Bash on Windows (Ubuntu) - 16.04
Git - 2.11.0
VS Code - 1.12.1

1. Open a command prompt and enter bash
2. Navigate to any directory under /mnt/c/Users/<username>
3. Clone an empty repository into the current directory.
   • If you don't already have an empty repository, create one on github first.
4. From the bash terminal, open the cloned repository folder with vs-code.
   • Notice the terminal stops accepting input, but you can Ctrl+C out of this. Unexpected
5. From the same bash terminal, enter the following command:
   git subtree add --prefix third_party/catch https://github.com/philsquared/catch master --squash
   • Notice the error Working tree has modificiations. Cannot add. Unexpected

Similar issues occur if you try to rm -rf the folder while open with vs-code but this isn't quite so unusual.

[therealkenc]

I was going to speculate the problem was the with a file being pinned by Windows (per usual), but that isn't it -- the second open without O_NOATIME succeeds. Full strace here. This is on 16193.

[pid   528] access(".git/objects/8d/6cfe03ceed8dd607093137e6b4b1f7061d4c4c", F_OK) = 0
[pid   528] open(".git/objects/8d/6cfe03ceed8dd607093137e6b4b1f7061d4c4c", O_RDONLY|O_NOATIME) = -1 EPERM (Operation not permitted)
[pid   528] open(".git/objects/8d/6cfe03ceed8dd607093137e6b4b1f7061d4c4c", O_RDONLY) = 3
[pid   528] fstat(3, {st_mode=S_IFREG|0777, st_size=218, ...}) = 0

[redbaron]

@rtlayzell , what does git status say? does git config core.filemode false issued in a cloned dir help?

[rtlayzell]

git status says there is nothing to commit, and the working tree is clean. (rightfully so).
Also core.filemode is already false 😢

[therealkenc]

In my test git status says the coast is clear, even with code open. Once code is closed the add takes. The problem isn't sticky. I want to blame #1956, because the only thing code would be doing is watching (I think). I didn't track it far enough to see what handles are open on the win32 side. Kind of curious because the object file does open.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!