Re: BUG: fast-import, ftruncate, and file mode

[Phillip Wood <phillip.wood123@gmail.com>]

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