From: Phillip Wood Date: Wed, 23 Feb 2022 13:59:10 GMT Subject: Re: BUG: fast-import, ftruncate, and file mode Message-ID: <3bdff4ba-fb5f-e369-306d-5510ab20893a@gmail.com> In-Reply-To: On 23/02/2022 07:47, Elijah Newren wrote: > Hi, > > fast-import makes use of odb_mkstemp(), which creates a secure > temporary file and opens it with mode 0444, and then uses it for its > packfile writing. Sometimes, fast-import will call its > truncate_pack() function, which makes use of ftruncate(). > > According to my local manpage, "With ftruncate(), the file must be > open for writing; with truncate(), the file must be writable." > > The writable requirement does not appear to be enforced by the kernel > on common filesystems like ext4 or zfs, but this is enforced on some > filesystems. Apparently a "VxFS Veritas filesystem" got triggered by > this...and some helpful bug reporters tracked this problem down and > found a workaround (for the filter-repo usecase, they recompiled a > special copy of git using mode 0644 for odb_mkstemp, since it was just > an intermediate step anyway and won't be used elsewhere). Am I missing something or is this really a file system bug? Surely if we have opened a file for writing the file permissions when we call ftruncate() should be irrelevant? Best Wishes Phillip > I'm not sure if we should (1) just stop calling truncate_pack() in > fast-import (it's merely an optimization), or (2) modify odb_mkstemp() > to allow specifying a mode and also have something like > finalize_object_file() modify the mode before renaming, or (3) if we > should do something else entirely. Someone more familiar with the > object storage side of things probably knows. But I'm guessing that > once someone who knows the area states what should be done, that this > might be a small micro-project suitable for the GSoC interns (or > anyone else wanting to get involved)? > > Original details from here: > https://github.com/newren/git-filter-repo/issues/342#issuecomment-1047638304