When fscache is used, "Function not implemented" messages are shown after 2.20

[shkit]

• [x ] I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options

git version 2.20.1.windows.1
cpu: x86_64
built from commit: 7c9fbc07db0e2939b36095df45864b8cda19b64f
sizeof-long: 4
sizeof-size_t: 8

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver

Microsoft Windows [Version 6.3.9600]

• What options did you set as part of the installation? Or did you choose the
  defaults?

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

The drive which stores repository data seems to be remote disk.
(I'm not Administrator and cannot know real hardware)

On other machine which have local disk, this issue seems not to show for me.
Therefore, this issue may depend what disk type is, I think.

Details

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

CMD

• What commands did you run to trigger this issue? If you can provide a
  Minimal, Complete, and Verifiable example
  this will help us understand the issue.

git status

• What did you expect to occur after running these commands?

without error messages

• What actually happened instead?

After 2.20, many "Function not implemented" messages are shown only under caffe2/operators directory in PyTorch repository.

> git status
Refresh index: 100% (5188/5188), done.
caffe2/operators/CMakeLists.txt: Function not implemented
caffe2/operators/abs_op.cc: Function not implemented
caffe2/operators/abs_op.cu: Function not implemented
...
caffe2/operators/zero_gradient_op.cc: Function not implemented
caffe2/operators/zero_gradient_op.h: Function not implemented
caffe2/operators/zero_gradient_op_gpu.cc: Function not implemented
warning: could not open directory 'caffe2/operators/': Function not implemented
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

If I disable fscahe, these messages are not shown.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

I found these repository and not found other repositories that this issue occurs.

• https://github.com/pytorch/pytorch.git

[dscho]

Obviously, I cannot reproduce, otherwise I would not have released Git for Windows v2.20.1 in the current form. I cloned all 90+ megabytes of your MCVE (not very "minimal", I must say), and a git status does not show the problems you report:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

nothing to commit, working tree clean

It would be good if you could verify that a fresh clone of said repository reproduces the issue for you, and if it does not, work on making that MCVE complete.

[shkit]

@dscho Yes, this was not "minimal" report. Sorry...
When I try a fresh clone, I cannot see any problems. I suppose my repository was corrupted.
Thanks for investigating!

[dozius]

I have the same or similar issue. It seems to only affect repositories on network drives. I was able to reproduce on any repo I copied from my local drive to a network drive. Even a simple, newly created repo with one file named test.txt had the same problem. Here is the output from that repo.

test.txt: Function not implemented
fatal: cannot use .git/info/exclude as an exclude file

Disabling the fscache, reverting to 2.19.1 or moving the repo to the local drive fixes the problem.

I see there were changes to the caching in 2.19.2 and 20.0.0. Even tough it was reverted to pre-release, I can try out 2.19.2 when I am back at work to try to narrow things down.

I am running git from cmd/powershell, not bash. Win7 x64. Servers are all under I.T. control, but I can try to find out what they are running. If there is anything else I can do to gather more info, just let me know and I will give it try.

[dozius]

aaaaand this was closed as I was typing. If you want me to open a new issue, let me know and I will do so.

[shkit]

@dscho Sorry again. I forget disabling fscache.
I re-try to clone PyTorch repository with fscache, I see issue is still exists.
My verification is this. More "minimal" examples are not found at this time...

git clone https://github.com/pytorch/pytorch.git
cd pytorch
git status

@dozius thanks for comment.
Yes, this issue occrus on network drive in my environment too.
But this issue seems not to happen with Samba. I suppose some proprietry implementation not support some function and cause this issue.

[dozius]

Confirmed the issue is not present in 2.19.2. I would guess the change that broke things was part of #1937.

I had a quick peak and perhaps it has something to do with the handle being passed to NtQueryDirectoryFile being created with CreateFile instead of NtCreateFile as the documentation suggests.

I'm no expert on win internals, but I know the public API handles a lot of path ugliness for you before it's passed to the internals. I wouldn't be surprised if something special for UNC paths was missed.

[chrisrapson]

This issue affects me too. See here for details:
https://stackoverflow.com/questions/54209815/git-status-is-giving-function-not-implemented-and-fatal-cannot-use-git-info/

[dscho]

The obvious workaround is to set core.fscache = false. While not satisfying, it gets you unblocked.

The real fix(es) will have to wait until somebody with enough energy and knowledge will get the time to investigate this.

[dscho]

I would guess the change that broke things was part of #1937.

This is indeed the very culprit, and the fix would be to (partially) reinstate the previous version when the current version fails.

[dozius]

Turning fscache off is way too slow in my case. I've reverted to the previous release to keep going, which is fine for now.

@benpeart, when you have some time could you look into this?

[benpeart]

Yes @dozius, I'll look into how to get fscache working better with network drives. Thanks for letting me know about the issue.