Re: [PATCH v2 0/6] Implement a batched fsync option for core.fsyncObjectFiles

On Tue, Sep 7, 2021 at 6:23 PM Ævar Arnfjörð Bjarmason [off-list ref] wrote:

On Tue, Sep 07 2021, Neeraj Singh wrote:

quoted

On Tue, Sep 7, 2021 at 12:54 PM Randall S. Becker
[off-list ref] wrote:

quoted

On September 7, 2021 3:44 PM, Neeraj Singh wrote:

quoted

On Fri, Aug 27, 2021 at 4:49 PM Neeraj K. Singh via GitGitGadget [off-list ref] wrote:

quoted

Thanks to everyone for review so far! I've responded to the previous
feedback and changed the patch series a bit.

Changes since v1:

 * Switch from futimes(2) to futimens(2), which is in POSIX.1-2008. Contrary
   to dscho's suggestion, I'm still implementing the Windows version in the
   same patch and I'm not doing autoconf detection since this is a POSIX
   function.

While POSIX.1-2008, this function is not available on every single
POSIX-compliant platform. Please make sure that the code will not
cause a breakage on some platforms - the ones I maintain, in
particular. Neither futimes nor futimens is available on either
NonStop ia64 or x86. The platform only has utime, so this needs to
be wrapped with an option in config.mak.uname.

Thanks,
Randall

Ugh. Fair enough.  How do other contributors feel about me moving back
to utime, but instead just doing the utime over in
builtins/pack-objects.c?  The idea would be to eliminate the mtime
logic entirely from write_loose_object and just do it at the top-level
in loosen_unused_packed_objects.

Aside from where it lives, can't we just have a wrapper that takes both
the filename & fd, and then on some platforms will need to dispatch to a
slower filename-only version, but can hopefully use the new fd-accepting
function?

I had some concerns around using utime() while a file descriptor is open.
There's some risk of sharing violation on Windows (doesn't matter since we'd
be using futimens), but I was also concerned that there might be some OSes that
update the mtime on close(fd), thus overwriting the effects of utime.
Maybe that's an unwarranted concern, but it's part of why I didn't want to have
different call sequences on different OSes.

I'd be happy to implement your suggestion though and see what happens. But I
also feel that this time update thing is pretty ancillary to the real
goal of my change.
I'm only doing it because it's in the same area. The effects of
getting mtime wrong
would be pretty subtle -- I think we'd just not be deleting some
unpacked unreachable
objects as soon as expected.  Do you have a strong objection to
lifting the time update
logic out?