pr-1291/dscho/enotdir-and-enoent-can-indicate-missing-refs-v1
tagged this
15 Jul 08:06
From: Pierre Garnier <pgarnier@mega.com> Network shares sometimes use aggressive caching, in which case a just-created directory might not be immediately visible to Git. One symptom of this scenario is the following error: $ git tag -a -m "automatic tag creation" test_dir/test_tag fatal: cannot lock ref 'refs/tags/test_dir/test_tag': unable to resolve reference 'refs/tags/test_dir/test_tag': Not a directory Note: This does not necessarily happen in all Windows setups. One setup where it _did_ happen is a Windows Server 2019 VM, and as hinted in http://woshub.com/slow-network-shared-folder-refresh-windows-server/ the following commands worked around it: Set-SmbClientConfiguration -DirectoryCacheLifetime 0 Set-SmbClientConfiguration -FileInfoCacheLifetime 0 Set-SmbClientConfiguration -FileNotFoundCacheLifetime 0 This would impact performance negatively, though, as it essentially turns off all caching, therefore we do not want to require users to do that just to be able to use Git on Windows. The underlying culprit is that `GetFileAttributesExW()` that is called from `mingw_lstat()` can raise an error `ERROR_PATH_NOT_FOUND`, which is translated to `ENOTDIR`, as opposed to `ENOENT` as expected on Linux. Therefore, when trying to read a ref, let's allow `ENOTDIR` in addition to `ENOENT` to indicate that said ref is missing. This fixes https://github.com/git-for-windows/git/issues/3727 Signed-off-by: Pierre Garnier <pgarnier@mega.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Submitted-As: https://lore.kernel.org/git/pull.1291.git.1657872416216.gitgitgadget@gmail.com
Assets 2
-
2022-07-15T08:06:56Z -
2022-07-15T08:06:56Z -