Git development
 help / color / mirror / Atom feed
From: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
To: Junio C Hamano <gitster@pobox.com>
Cc: GIT Mailing-list <git@vger.kernel.org>
Subject: Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
Date: Tue, 24 Nov 2009 20:07:41 +0000	[thread overview]
Message-ID: <4B0C3D0D.60309@ramsay1.demon.co.uk> (raw)
In-Reply-To: <7veinrnym4.fsf@alter.siamese.dyndns.org>

Junio C Hamano wrote:
> Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> 
>> I haven't tried this patch, but I think you may need to add something like
>> the following (*not tested*):
>>
>> --- >8 ---
>> diff --git a/compat/cygwin.c b/compat/cygwin.c
>> index b4a51b9..7e9edec 100644
>> --- a/compat/cygwin.c
>> +++ b/compat/cygwin.c
>> @@ -53,6 +53,7 @@ static int do_stat(const char *file_name, struct stat *buf, stat_fn_t cygstat)
>>  		buf->st_size = (off_t)fdata.nFileSizeLow;
>>  #endif
>>  		buf->st_blocks = size_to_blocks(buf->st_size);
>> +		buf->st_blksize = 512;
>>  		filetime_to_timespec(&fdata.ftLastAccessTime, &buf->st_atim);
>>  		filetime_to_timespec(&fdata.ftLastWriteTime, &buf->st_mtim);
>>  		filetime_to_timespec(&fdata.ftCreationTime, &buf->st_ctim);
>> --- >8 ---
> 
> Doesn't this contradict with everything you said?

Err... no :-D

Note that my suggested addition to your patch is in the core.filemode == false
code path, and so does not affect the "disk-space under-estimate" problem at all.

[To be clear: the "disk-space under-estimate" problem only happens when
core.filemode == true and the regular cygwin lstat()/stat() functions are used.
When core.filemode == false, the code in compat/cygwin.c (namely cygwin_lstat()
and cygwin_stat()) will (most likely) be called instead. These functions use
WIN32 api calls to implement equivalent, but presumably faster, versions of the
stat functions]

> You are forcing st_blksize to 512 but still return the same old st_blocks;
> I do not understand what that would achieve.

Well, as I said, I haven't tested your patch, or my suggested addition, so I could
well be wrong... but what I aimed to achieve was to:

    - avoid "undefined behaviour" in on_disk_bytes(), since the value in
      st_blksize would otherwise be undefined (ie whatever happened to be
      on the stack-frame of the count_objects() function).
    - initialize the st_blksize field with a value consistent with the
      st_blocks field, which is derived from the st_size field, as the
      number of 512-byte blocks. (see the context line just before the
      + line in the above diff, along with the size_to_blocks macro)
    - return the same answer from this code as before.

Note that the answer returned from this core.filemode == false code path
is different to the core.filemode == true code path. Which is why I *slightly*
prefer my original patch.

HTH.

ATB,
Ramsay Jones

  reply	other threads:[~2009-11-24 20:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-11-19 18:46 [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin Ramsay Jones
2009-11-20  7:00 ` Junio C Hamano
2009-11-20  7:49   ` Junio C Hamano
2009-11-21  0:00     ` Ramsay Jones
2009-11-22  1:21       ` Junio C Hamano
2009-11-24 20:07         ` Ramsay Jones [this message]
2009-11-24 22:08           ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4B0C3D0D.60309@ramsay1.demon.co.uk \
    --to=ramsay@ramsay1.demon.co.uk \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox