06ee913c8d
If we need to append less than 20 bytes in order to fix a thin pack and make it complete, we need to set the length of our file back to the actual number of bytes used because the original SHA-1 footer was not completely overwritten. That extra data will confuse the header and footer fixup logic when it tries to read to the end of the file. This isn't a very common case to occur, which is why we've never seen it before. Getting a delta that requires a whole object which uses less than 20 bytes in pack representation is really hard. Generally a delta generator won't make these, because the delta would be bigger than simply deflating the whole object. I only managed to do this with a hand-crafted pack file where a 1 byte delta was pointed to a 1 byte whole object. Normally we try really hard to avoid truncating, because its typically not safe across network filesystems. But the odds of this occurring are very low. This truncation is done on a file we have open for writing, will append more content onto, and is a temporary file that we won't move into position for others to see until we've validated its SHA-1 is sane. I don't think the truncate on NFS issue is something we need to worry about here. Change-Id: I102b9637dfd048dc833c050890d142f43c1e75ae Signed-off-by: Shawn O. Pearce <spearce@spearce.org> |
||
|---|---|---|
| .. | ||
| .settings | ||
| META-INF | ||
| findBugs | ||
| src/org/eclipse/jgit | ||
| .classpath | ||
| .fbprefs | ||
| .gitignore | ||
| .project | ||
| about.html | ||
| build.properties | ||
| plugin.properties | ||
| pom.xml | ||