Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

multi-pack-index expire doesn't do anything if --objects-dir contains backward slashes #497

Closed
2 of 6 tasks
nikola-sh opened this issue Apr 21, 2022 · 1 comment · Fixed by #498
Closed
2 of 6 tasks
Assignees

Comments

@nikola-sh
Copy link

VFSForGit runs PackfileMaintenanceStep periodically, but content of pack subdirectory in .gvfsCache remains unchanged.
The reason is that git multi-pack-index expire command doesn't work with backward slash paths for --object-dir (see reproduction example below).
So VFSForGit runs expire with backward slashes and it doesn't do anything.
It seems git behavior should not depend on paths format.

Setup

  • Which version of microsoft/git are you using? Is it 32-bit or 64-bit?
git version 2.36.0.vfs.0.0
cpu: x86_64
built from commit: 5323cc6ccf2923f4f41da713ea9d1125704dec5b
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

Are you using Scalar or VFS for Git?

VFS for Git

If VFS for Git, then what version?

$ gvfs version

v1.0.21229.1
  • 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 10.0.19044.1645]
  • Any other interesting things about your environment that might be related
    to the issue you're seeing?

no

Details

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

CMD

If you run multi-pack-index expire with backward slashes for --object-dir command do nothing

c:\Windows>"C:\Program Files\Git\mingw64\bin\git.exe" --git-dir="F:\Projects\Monorepo\src\.git" -c core.virtualizeobjects=false multi-pack-index expire --object-dir="F:\.gvfsCache\d7745fd3f2f047bab6827f5b183fdbf0\gitObjects"
13:16:41.308775 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
13:16:41.310776 run-command.c:1549      run_processes_parallel: preparing to run up to 1 tasks
13:16:41.310776 run-command.c:654       trace: run_command: F:/Projects/Monorepo/src/.git/hooks/pre-command.exe multi-pack-index expire '--object-dir=F:\.gvfsCache\d7745fd3f2f047bab6827f5b183fdbf0\gitObjects' --git-pid=31564
13:16:41.404016 run-command.c:1581      run_processes_parallel: done
13:16:41.404016 git.c:531               trace: built-in: git multi-pack-index expire '--object-dir=F:\.gvfsCache\d7745fd3f2f047bab6827f5b183fdbf0\gitObjects'
13:16:41.410589 run-command.c:1549      run_processes_parallel: preparing to run up to 1 tasks
13:16:41.410589 run-command.c:654       trace: run_command: F:/Projects/Monorepo/src/.git/hooks/post-command.exe multi-pack-index expire '--object-dir=F:\.gvfsCache\d7745fd3f2f047bab6827f5b183fdbf0\gitObjects' --git-pid=31564 --exit_code=0
13:16:41.497558 run-command.c:1581      run_processes_parallel: done

Command starts doing smth with forward slashes for --object-dir:

c:\Windows>"C:\Program Files\Git\mingw64\bin\git.exe" --git-dir="F:\Projects\Monorepo\src\.git" -c core.virtualizeobjects=false multi-pack-index expire --object-dir="F:/.gvfsCache/d7745fd3f2f047bab6827f5b183fdbf0/gitObjects"
13:16:56.612496 exec-cmd.c:237          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
13:16:56.615528 run-command.c:1549      run_processes_parallel: preparing to run up to 1 tasks
13:16:56.615528 run-command.c:654       trace: run_command: F:/Projects/Monorepo/src/.git/hooks/pre-command.exe multi-pack-index expire --object-dir=F:/.gvfsCache/d7745fd3f2f047bab6827f5b183fdbf0/gitObjects --git-pid=34208
13:16:56.715399 run-command.c:1581      run_processes_parallel: done
13:16:56.715399 git.c:531               trace: built-in: git multi-pack-index expire --object-dir=F:/.gvfsCache/d7745fd3f2f047bab6827f5b183fdbf0/gitObjects
Unlink of file 'F:/.gvfsCache/d7745fd3f2f047bab6827f5b183fdbf0/gitObjects/pack/from-loose-922b0b1f773d613ed0ae0a493433d10461ae7c4f.idx' failed. Should I try again? (y/n)
  • If the problem was occurring with a specific repository, can you specify
    the repository?

    • Public repo: insert URL here
    • Windows monorepo
    • Office monorepo
    • Other Microsoft-internal repo: insert name here
    • Other internal repo.
@derrickstolee
Copy link
Collaborator

Thanks, @nikola-sh. I've confirmed that VFS for Git sends the path in the format you are describing AND that the expire (and repack) commands do nothing here.

The root cause is an upstream change in how we found the existing multi-pack-index from the given --object-dir in a more-strict way than before.

This bug only affects VFS for Git. Scalar uses Git's background maintenance, which passes the paths in the Unix style already.

I'll send a fix into microsoft/git soon, but it also applies upstream.

@derrickstolee derrickstolee self-assigned this Apr 21, 2022
derrickstolee added a commit that referenced this issue May 4, 2022
…t-dir

This resolves #497.

Looking at this, it seems that VFS for Git users have not been getting all of the benefits of background maintenance for quite some time. This will probably justify a `v2.36.0.vfs.0.1` release for those users. We should wait for upstream feedback, first. I will prepare an upstream patch soon.
dscho pushed a commit that referenced this issue Jun 17, 2022
…t-dir

This resolves #497.

Looking at this, it seems that VFS for Git users have not been getting all of the benefits of background maintenance for quite some time. This will probably justify a `v2.36.0.vfs.0.1` release for those users. We should wait for upstream feedback, first. I will prepare an upstream patch soon.
dscho pushed a commit that referenced this issue Jun 17, 2022
…t-dir

This resolves #497.

Looking at this, it seems that VFS for Git users have not been getting all of the benefits of background maintenance for quite some time. This will probably justify a `v2.36.0.vfs.0.1` release for those users. We should wait for upstream feedback, first. I will prepare an upstream patch soon.
dscho pushed a commit that referenced this issue Jun 17, 2022
…t-dir

This resolves #497.

Looking at this, it seems that VFS for Git users have not been getting all of the benefits of background maintenance for quite some time. This will probably justify a `v2.36.0.vfs.0.1` release for those users. We should wait for upstream feedback, first. I will prepare an upstream patch soon.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants