Git: FAILURE DUE TO CORRUPTED FILE: remote: error: inflate: data stream error ... remote: error: unable to unpack ... remote: fatal: loose object ... error: remote unpack failed:

 

>PROBLEM

An attempt to update the local repository using pull and push fails returning the following message:

...

! [remote rejected] master -> master (unpacker error)

remote: error: inflate: data stream error (unknown compression method)

remote: error: unable to unpack a798a0e5cdf6ab498ea641c3d8d7b5763dc901d0 header

remote: fatal: loose object a798a0e5cdf6ab498ea641c3d8d7b5763dc901d0 (stored in //10.0.0.7/j/git/code/objects/a7/98a0e5cdf6ab498ea641c3d8d7b5763dc901d0) is corrupt

error: remote unpack failed: unpack-objects abnormal exit

$git checkout -f HEAD

error: unable to read sha1 file of css_grid.diff (a798a0e5cdf6ab498ea641c3d8d7b5763dc901d0)

error: inflate: data stream error (invalid distance too far back)

error: corrupt loose object '8711ded8021f5a4f59db8899e25c30655e80e803'

fatal: loose object 8711ded8021f5a4f59db8899e25c30655e80e803 (stored in .git/objects/87/11ded8021f5a4f59db8899e25c30655e80e803) is corrupt

Another attempt to clone the repository also fails, returning:

git clone \\10.0.0.7\j\git\code

Cloning into 'code'...

done.

error: unable to read sha1 file of css_grid.diff (a798a0e5cdf6ab498ea641c3d8d7b5763dc901d0)

error: inflate: data stream error (invalid distance too far back)

error: corrupt loose object '8711ded8021f5a4f59db8899e25c30655e80e803'

fatal: loose object 8711ded8021f5a4f59db8899e25c30655e80e803 (stored in L:/transp/1___downloads/code/.git/objects/87/11ded8021f5a4f59db8899e25c30655e80e803) is corrupt

warning: Clone succeeded, but checkout failed.

You can inspect what was checked out with 'git status'

and retry the checkout with 'git checkout -f HEAD'

>SOLUTION

The attempt to clone was used to make sure that the corruption happened on remote repository.
After some research, the best documentation to fix this was "Recovering from repository corruption" but also comments that against corruption the best alternative is a backup.
Although having backups, it didn't help in this case because the backups also had exactly the same issue since a backup is a copy. Because it is not an incremental copy, the backup was useless.

SAVING THE PAST

Faster than trying to fix it for the sake of time saving, the corrupted remote repository was renamed from "code" to "code_corrupted_200220" and saved its copy.

ren code code_corrupted_200220

or

mv code code_corrupted_200220 (linux)

This backup may be used to get some previous commit, or even an attempt to fix it if really necessary just because it is required an old version of a file. Since "clone" command was able to clone to local repository although the warning, this corrupted remote repository is still useful to recover old stuff.

GOING AHEAD WITH THE FUTURE

It was created a new remote repository:
mkdir clone
cd clone

git init --bare

A new remote repository with a new log  history.
The old one is preserved in the backup mentioned above, just in case.

Next step is to push the local repositories.
The procedure was usual except that it is required to set upstream, resembling the procedure when a remote repository is switched (git remote remove origin, git remote add origin new_path).

git add *
git commit -am "MACHINE_NAME: corrupted remote repository switching"
git pull origin master
git push --set-upstream origin master

The same procedure was repeated to all local clients.

One day, if fixing the corruption is worthy, we may try the "Recovering from repository corruption" instructions, but till there, maybe Git will bring redundancy option to duplicate the tree.
In such cases it would be useful to have two files in different positions on the disk, in order to recover the information from a particular damaged disk position. This should be really an option because it would double the resources' requirement, but sometimes it is a desirable option if hardware has the power to supply this redundancy without being noticeable and disk space is not a restriction.

The full disk was checked successfully. No errors found, except this occurrence.

Murphy's day.  :-)

>ENV

Windows 10

git v.2.30.1.windows.1

How to use VS Code with Multiple Configurations with Backup

>PROBLEM

You need to work with different environments and workspaces for different purposes when working with different programming languages or different contexts.

For each context or environment, you've installed the desired extensions.

Also, it is interesting to keep a backup of the environment to save time.

What does happen next?

If you have just one configuration setup and many needs, the VS Code configuration begins growing, eventually getting heavy, slow, and taking too much memory.

Also, the extensions' default shortcuts begin to conflict with each other.

>SOLUTION

There are at least three approaches:

1. Versioning control using branches, or

2. Separate configuration folders, or

3. Option 1 plus option 2.

Versioning control using branches

The VS Code default folder that holds its configuration setup is under

      "C:\Users\YOUR_LOGIN\.vscode" folder.

Create a git repository there.

For each kind of environment desired, create a specific branch.

The master branch would aggregate everything, but in this case, there is no use unless you do want to keep a backup of just one setup.

Separate configuration folders

It is possible to switch environments using commands.

To do this, it is necessary to create a symbolic link to the current default extensions folder used by VS Code by default.

The default folder is at:

%USERPROFILE%\.vscode\extensions

Before creating the symbolic link, move the default extension folder to the new place desired, then create it:

mklink /D %USERPROFILE%\.vscode\extensions "NEW_PATH_DESIRED\extensions"

Ex.:
mklink /D C:\Users\YOUR_USER\.vscode\extensions "D:\ide_home\vscode\Code\extensions"

Option 1 plus option 2

You may combine the two options above, but better if the branches keep a keyword to avoid losing control.

The best of all is that you never lose your env, never need to reconfigure, and may switch fast the environments preserving then VS Code app from getting messed and slow.

ATTEMPT FAILURE NOTE

The attempt using "--user-data-dir" and/or  "--extensions-folder" flags (options) was not successful by the time I've tried using VS Code  v.1.53.2.

Blue Screen with one of the following messages: windows system error STATUS_WAIT_2 0x80070002 or windows system error STATUS_WAIT_3 0x80070003

>PROBLEM

When rebooting the machine, returned blue screen with the following message:

  windows system error STATUS_WAIT_3 0x80070003

Another attempt, returned another message:

  windows system error STATUS_WAIT_2 0x80070002

  

>SCENARIO

The machine was very, very slow, and once in a while appeared "bad clusters". This situation took several weeks. During all this time, the checklist below passed:

HD fragmentation: OK

HD S.M.A.R.T. status and test: OK

Scandisk: no errors, OK

Antivirus: disabled during the tests.

Unexpected processes consuming CPU's resources: none

Internet connection: disabled

All programs closed, just the usual services were turned on.

Hardware temperature: OK

Windows Registry: OK

Suddenly, when a reboot is done, the blue screen with the messages.

All attempts possible were performed — all "Windows Recovery" options failed, returning messages like "not possible", "done but failed", and things like that. Fixing reboot, cloning a new reboot partition from a backup HD, attempt to restore an image or restore the system from a "restore point" and etc. had failed.

>SOLUTION

The HD was removed from the slot and inserted back twice.

An intermittent bad contact caused maybe by slight oxidation, dust, vibration, etc. was causing the unexpected "bad blocks".

In this scenario, the Windows system made an automatic update that was not able to get to the end.

Considering the two problems together plus interrupted update procedure, the mess was complete.

The solution came, after solving the contact issue, let Windows finishes the update. Long and twice, but the issue was solved but the system was inconsistent, missing several DLLs, requiring more one more solution.

This time at least was possible to restore to a previous point before the unlucky Windows update and perform again that required update.

When rare events happen to get together at the same time, just Murphy explains!  :-)

Eventually, the system was up and running again!

Well done Windows!!! Wow!!!

>ENV

Windows 10