Re: problem with modification time of packfiles

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Oct 18, 2015 at 10:37:55PM +0100, Andreas Amann wrote:
> git (2.6.1) sometimes updates the modification time of a packfile, even if it
> has not changed at all.
> 
> On my system this triggers quite expensive an d unnecessary backup
> operations, which I would prefer to avoid.  Is there a simple way to
> keep the mtime of packfiles fixed, once they are created?
> 
> Apparently the undesired mtime update is done in
> sha1_file.c:freshen_file() which is called (indirectly) by
> write_sha1_file().  However I did not understand, why this is done.
> 
> Any clarification and pointers, how mtime can be kept constant would be
> appreciated.

This is required to avoid deleting items that might still be needed.
The commit message for the commit that introduced that function is as
follows:

  write_sha1_file: freshen existing objects
  
  When we try to write a loose object file, we first check
  whether that object already exists. If so, we skip the
  write as an optimization. However, this can interfere with
  prune's strategy of using mtimes to mark files in progress.
  
  For example, if a branch contains a particular tree object
  and is deleted, that tree object may become unreachable, and
  have an old mtime. If a new operation then tries to write
  the same tree, this ends up as a noop; we notice we
  already have the object and do nothing. A prune running
  simultaneously with this operation will see the object as
  old, and may delete it.
  
  We can solve this by "freshening" objects that we avoid
  writing by updating their mtime. The algorithm for doing so
  is essentially the same as that of has_sha1_file. Therefore
  we provide a new (static) interface "check_and_freshen",
  which finds and optionally freshens the object. It's trivial
  to implement freshening and simple checking by tweaking a
  single parameter.
  
  Signed-off-by: Jeff King <peff@xxxxxxxx>
  Signed-off-by: Junio C Hamano <gitster@xxxxxxxxx>

Perhaps implementing a backup strategy based on content instead of mtime
would be more successful.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
+1 832 623 2791 | https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: RSA v4 4096b: 88AC E9B2 9196 305B A994 7552 F1BA 225C 0223 B187

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]