Zero-padded file modes in repository

[divad]

After cloning this repository with git and you run "git fsck" there are multiple errors:

Checking object directories: 100% (256/256), done. warning in tree 0b404df8c030cdeaca7b373956c3a697efd32f78: contains zero-padded file modes warning in tree 51ea366fd4253b3a618289dc1c0c4bb16a3c2a22: contains zero-padded file modes warning in tree 679afdb340e9e1011927b52d2cd48bd221159131: contains zero-padded file modes warning in tree 77c7430020693d35500ca4fc292cff63fc3e672b: contains zero-padded file modes warning in tree 6a37da079f3bed362608b2558b162617c0c3af5c: contains zero-padded file modes Checking objects: 100% (12634/12634), done.

This prevents the repository from being push'ed to another git server, for example:

Counting objects: 12435, done. Delta compression using up to 8 threads. Compressing objects: 100% (3696/3696), done. remote: error: object 0b404df8c030cdeaca7b373956c3a697efd32f78: zeroPaddedFilemode: contains zero-padded file modes remote: fatal: Error in object error: pack-objects died of signal 13

I suggest the repository is rebuilt to correct the corruption in it.

[ThiefMaster]

I'm quite sure we don't want to do any kind of rebuild that results in new commit hashes throughout the whole repo. Is there a way to fix this in a new commit?

[divad]

They are only warnings, so one option is to simply note the error on a documentation page somewhere with a suggested workaround (change your git config to turn off fsck on object transfers). I think this would help others who come across the problem.

The general workaround is indeed to ignore the errors. I think GitHub itself does this so that when you push changes to GitHub an fsck isn't done on objects so they push cleanly. Some git hosting software doesn't do this though, I hit the issue when upload flask to GitLab (self-hosted) and found it rejected pushing the whole repository. This is a rare use case however.

The standard option I found when researching was to do a rebuild via git fast-export/fast-import, but as you say this option is not acceptable as all the hashes change and tree references are lost.

There is a discussion about this happening to another repo here: holman/dotfiles#231

I'm afraid I'm out of my depth to help much more than this, unless the project has some git experts I would suggest documenting the corrupted objects somewhere in the repo docs and closing this issue.

[untitaker]

We can always document something, but I'm not sure how useful that would be. If somebody wants to spare that effort I'll merge it though :) Probably would belong in the CONTRIBUTING.rst rather than the sphinx docs.

[sahildua2305]

I can add it there. @untitaker

According to me, git config fetch.fsckObjects false will be the solution for this error.
Or here's alternative solution - git config --global fsck.zeroPaddedFilemode ignore

Which one is better?

[untitaker]

The latter I think

On 27 September 2016 22:15:29 CEST, Sahil Dua [email protected] wrote:

I can add it there. @untitaker

According to me, git config fetch.fsckObjects false will be the
solution for this error.
Or here's alternative solution - git config --global fsck.zeroPaddedFilemode ignore

Which one is better?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2029 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.

[sahildua2305]

Cool, makes sense!

So should I just add a different section in the end named something like 'Caution' in CONTRIBUTING.rst (since there's no such section right now)?

[untitaker]

That's one option though to be honest I haven't looked much into it

On 27 September 2016 22:26:44 CEST, Sahil Dua [email protected] wrote:

Cool, makes sense!

So should I just add a different section in the end named something
like 'Caution' in CONTRIBUTING.rst (since there's no such section
right now)?

You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub:
#2029 (comment)

Sent from my Android device with K-9 Mail. Please excuse my brevity.