contenthash: unconditionally clear ModeIrregular during content hash #6025
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
jsternberg
force-pushed
the
unconditional-clear-mode-irregular
branch
from
bbd5249 to
df01637
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR simplifies the logic in NewFromStat to unconditionally clear the ModeIrregular bit (in addition to the already-cleared socket bit) for compatibility with archive/tar.FileInfoHeader.
- Remove conditional clearing of
ModeIrregular - Add unconditional clearing of both
ModeSocketandModeIrregular - Update comment to describe both bits at once
Comments suppressed due to low confidence (2)
cache/contenthash/filehash.go:44
- [nitpick] Minor grammar: change
do not handle themtodoes not handle themsincearchive/tar.FileInfoHeaderis singular.
// Clear the socket and irregular bits since archive/tar.FileInfoHeader do not handle them
cache/contenthash/filehash.go:45
- [nitpick] Consider combining the two bit-clearing operations into one expression, e.g.,
stat.Mode &^= uint32(os.ModeSocket | os.ModeIrregular), to reduce duplication.
stat.Mode &^= uint32(os.ModeSocket)
Go 1.23 changed the behavior of `os.Stat` to set `ModeIrregular` when it encountered a mount point reparse point on Windows. These were previously labeled as symlinks. We attempted to fix this by clearing `ModeIrregular` during checksum generation, but we only cleared it in the case where `ModeIrregular` and at least one other mode type was set. After reviewing the original solution and issue, I believe that this was too conservative. The original issue seems to indicate that only the `ModeIrregular` bit was set so the condition would not have triggered and cleared it properly. I thought mount points would have both `ModeDir` and `ModeIrregular` set, but they only seem to have `ModeIrregular` set. This unconditionally clears the bit similar to socket files which should properly fix the issue on Windows. Signed-off-by: Jonathan A. Sternberg <[email protected]>
jsternberg
force-pushed
the
unconditional-clear-mode-irregular
branch
from
df01637 to
450362a
Compare
tonistiigi
approved these changes
Jun 11, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Go 1.23 changed the behavior of
os.Statto setModeIrregularwhen itencountered a mount point reparse point on Windows. These were
previously labeled as symlinks.
We attempted to fix this by clearing
ModeIrregularduring checksumgeneration, but we only cleared it in the case where
ModeIrregularandat least one other mode type was set.
After reviewing the original solution and issue, I believe that this was
too conservative. The original issue seems to indicate that only the
ModeIrregularbit was set so the condition would not have triggeredand cleared it properly. I thought mount points would have both
ModeDirandModeIrregularset, but they only seem to haveModeIrregularset.This unconditionally clears the bit similar to socket files which should
properly fix the issue on Windows.
Fixes docker/for-win#14083.
Related to #5665.