On Tue, Sep 7, 2021 at 6:23 PM Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> wrote: > > > On Tue, Sep 07 2021, Neeraj Singh wrote: > > > On Tue, Sep 7, 2021 at 12:54 PM Randall S. Becker > > <rsbecker@xxxxxxxxxxxxx> wrote: > >> > >> On September 7, 2021 3:44 PM, Neeraj Singh wrote: > >> >On Fri, Aug 27, 2021 at 4:49 PM Neeraj K. Singh via GitGitGadget <gitgitgadget@xxxxxxxxx> wrote: > >> >> > >> >> 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?
