As of 2.27.0, all symlinks have modifications after stash pop #2653

Tragetaschen · 2020-06-02T11:01:23Z

Setup

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

git version 2.27.0.windows.1
cpu: x86_64
built from commit: 907ab1011dce9112700498e034b974ba60f8b407
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?

Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.

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

Editor Option: VIM
Custom Editor Path:
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled
Enable Pseudo Console Support: Disabled

Details

Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
Windows Terminal (Preview) running PowerShell. I'm explicitly not running git from WSL (ever)
What commands did you run to trigger this issue?

> git stash
> git stash pop

What did you expect to occur after running these commands?
The number of modified files before and after the commands should be the same.
What actually happened instead?
I have read the release notes of 2.27.0 regarding the symlink behavior. I had the modified symlink files and ran git add -u on them. However, after stash and pop, all symlinks are back to the modified state even though they were not before.

Related: #2637
CC @billziss-gh

The text was updated successfully, but these errors were encountered:

Tragetaschen · 2020-06-02T12:32:50Z

Steps to reproduce in an empty folder within a PowerShell prompt:

> git init
Initialized empty Git repository in …/.git/
> echo "a" > a.txt
> cmd
Microsoft Windows [Version 10.0.18363.836]
(c) 2019 Microsoft Corporation. All rights reserved.


>mklink b.txt a.txt
symbolic link created for b.txt <<===>> a.txt
 Volume in drive C is OS
 Volume Serial Number is …

 Directory of …

02.06.2020  14:27    <DIR>          .
02.06.2020  14:27    <DIR>          ..
02.06.2020  14:27    <SYMLINK>      b.txt [a.txt]
               2 Dir(s)  171.432.267.776 bytes free

>exit
> dir


    Directory: …


Mode                LastWriteTime         Length Name
----                -------------         ------ ----
-a----       02.06.2020     14:27              8 a.txt
-a---l       02.06.2020     14:27              0 b.txt


> git add .
> git commit -m 'Commit'
[master (root-commit) 7761e65] Commit
 2 files changed, 1 insertion(+)
 create mode 100644 a.txt
 create mode 120000 b.txt
> echo "a" >> a.txt
> git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   a.txt

no changes added to commit (use "git add" and/or "git commit -a")
> git stash
Saved working directory and index state WIP on master: 7761e65 Commit
> git stash pop
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   a.txt
        modified:   b.txt

no changes added to commit (use "git add" and/or "git commit -a")
Dropped refs/stash@{0} (a10b62bae9d511cb63c13a103f28707a850da436)

Tragetaschen · 2020-06-03T14:47:19Z

I'm confused:

git gui does not show the modified status for the symlinks
git status on the command shows the modified status
Visual Studio's "Changes" tab in the Team Explorer shows the modified status

What's different in Git Gui?

dscho · 2020-06-03T21:23:15Z

What's different in Git Gui?

I guess that Git GUI parses the output of git diff, and that command does not report any changes.

Tragetaschen · 2020-06-04T14:00:09Z

Now things get weird. I'm in a second repository that largely resembles same symlink structure, but I never ran git add -u (if that matters). Here, the situation regarding the modified state is exactly the opposite to the first repository:

git status on the command line shows no modified status
Visual Studio's "Changes" tab in the Team Explorer shows no modified status
git gui does show the modified status for the symlinks, but when selecting the file in "Unstaged Changes", a dialog pops up:

git diff on the command line does not show anything for the symlinks.

dscho · 2020-06-07T13:15:31Z

I'm on my phone right now, so I cannot test: could you try again after running git config core.fscache false?

orgads · 2020-06-07T15:15:32Z

I have the same situation here. Every time I run git reset --hard (or merge, or other operations), all the symbolic links appear as modified, and only git add . helps.

I just checked setting core.fscache to false, and it solved the issue.

mrsvk · 2020-06-07T17:17:04Z

I see the same issue too - and it also happens when freshly cloning a repository containing symbolic links. My team is reverting to a prior version to avoid the issue for now.

orgads · 2020-06-07T19:18:24Z

Bisected to 2f55cc4 (obviously), and it is not fixed by f18046e6ae891fbb39087ef5386a46417e7b9b42.

In git-for-windows#2637, we fixed a bug where symbolic links' target path sizes were recorded incorrectly in the index. However, we did so only in `mingw_lstat()` but not in `fscache_lstat()`. Meaning: in code paths where the FSCache feature is enabled, Git _still_ got the wrong idea if the symbolic link target's length. Let's fix this. Note: as the FSCache feature reads in whole swaths of directory entries in batch mode, even if metadata for only one of them might be required, we save the expensive `CreateFile()` call that is required to compute the symbolic link target's length to the `fscache_lstat()` call. This fixes git-for-windows#2653. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2020-06-07T20:43:56Z

Bisected to 2f55cc4 (obviously), and it is not fixed by f18046e.

Right.

I think I have a correct and complete fix in #2673. @orgads would you mind testing it?

dscho · 2020-06-07T21:28:15Z

@Tragetaschen @mrsvk could I ask you to test the installer and/or portable Git generated from this PR? They can be found here: https://dev.azure.com/git-for-windows/git/_build/results?buildId=57380&view=artifacts&type=publishedArtifacts

Tragetaschen · 2020-06-07T21:30:26Z

Will do first thing tomorrow

mrsvk · 2020-06-07T21:40:47Z

@dscho I did the same simple test case I had done previously (git clone -> git status). The new build results in the expected clean status, instead of flagging every symlink. This looks to have resolved the issue for me - thank you.

orgads · 2020-06-08T05:16:55Z

Tested. It works for me. Thank you!

In #2637, we fixed a bug where symbolic links' target path sizes were recorded incorrectly in the index. However, we did so only in `mingw_lstat()` but not in `fscache_lstat()`. Meaning: in code paths where the FSCache feature is enabled, Git _still_ got the wrong idea if the symbolic link target's length. Let's fix this. Note: as the FSCache feature reads in whole swaths of directory entries in batch mode, even if metadata for only one of them might be required, we save the expensive `CreateFile()` call that is required to compute the symbolic link target's length to the `fscache_lstat()` call. This fixes #2653. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

Tragetaschen · 2020-06-08T07:35:04Z

I tested it in both my repositories and they behave normally now

Some Git operations [could end up with bogus modified symbolic links](git-for-windows/git#2653) (where `git status` would report changes but `git diff` would not), which is now fixed. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

In #2637, we fixed a bug where symbolic links' target path sizes were recorded incorrectly in the index. However, we did so only in `mingw_lstat()` but not in `fscache_lstat()`. Meaning: in code paths where the FSCache feature is enabled, Git _still_ got the wrong idea if the symbolic link target's length. Let's fix this. Note: as the FSCache feature reads in whole swaths of directory entries in batch mode, even if metadata for only one of them might be required, we save the expensive `CreateFile()` call that is required to compute the symbolic link target's length to the `fscache_lstat()` call. This fixes #2653. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho mentioned this issue Jun 7, 2020

Fix lstat()'s st_size computation for symbolic links when FSCache is in effect #2673

Merged

dscho closed this as completed in #2673 Jun 8, 2020

dscho added this to the Next release milestone Jun 8, 2020

dscho added bug git labels Jun 8, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

As of 2.27.0, all symlinks have modifications after stash pop #2653

As of 2.27.0, all symlinks have modifications after stash pop #2653

Tragetaschen commented Jun 2, 2020

Tragetaschen commented Jun 2, 2020

Tragetaschen commented Jun 3, 2020

dscho commented Jun 3, 2020

Tragetaschen commented Jun 4, 2020

dscho commented Jun 7, 2020

orgads commented Jun 7, 2020

mrsvk commented Jun 7, 2020

orgads commented Jun 7, 2020

dscho commented Jun 7, 2020

dscho commented Jun 7, 2020 •

edited

Loading

Tragetaschen commented Jun 7, 2020

mrsvk commented Jun 7, 2020

orgads commented Jun 8, 2020

Tragetaschen commented Jun 8, 2020

As of 2.27.0, all symlinks have modifications after stash pop #2653

As of 2.27.0, all symlinks have modifications after stash pop #2653

Comments

Tragetaschen commented Jun 2, 2020

Setup

Details

Tragetaschen commented Jun 2, 2020

Tragetaschen commented Jun 3, 2020

dscho commented Jun 3, 2020

Tragetaschen commented Jun 4, 2020

dscho commented Jun 7, 2020

orgads commented Jun 7, 2020

mrsvk commented Jun 7, 2020

orgads commented Jun 7, 2020

dscho commented Jun 7, 2020

dscho commented Jun 7, 2020 • edited Loading

Tragetaschen commented Jun 7, 2020

mrsvk commented Jun 7, 2020

orgads commented Jun 8, 2020

Tragetaschen commented Jun 8, 2020

dscho commented Jun 7, 2020 •

edited

Loading