Git archive doesn't fully support zip64
Dear git, git archive, when writing a zip file, has a silent 4GB file size limit (on the inputs as well as the output), as it doesn’t fully support zip64. Although a zip archive written by git which is larger than 4GB can be often still be unzipped, it won’t be fully useable and some tools (e.g. zipdetails) can’t read it at all. I suggest either git should be changed to fully support zip64 or it should give a proper error when either an input or the output is too large. Thanks, K.
Re: [PATCH v3 5/5] archive-zip: support files bigger than 4GB
This set of patches works for my test case. Thanks, K.
Git on Windows maps creation time onto changed time
Dear git,
While tracking down a problem with a filesystem shared by Windows and Ubuntu, I
came across the following code in compat/mingw.c (ming_fstat(), also in
do_lstat()):
if (GetFileInformationByHandle(fh, &fdata)) {
buf->st_ino = 0;
buf->st_gid = 0;
buf->st_uid = 0;
buf->st_nlink = 1;
buf->st_mode = file_attr_to_st_mode(fdata.dwFileAttributes);
buf->st_size = fdata.nFileSizeLow |
(((off_t)fdata.nFileSizeHigh)<<32);
buf->st_dev = buf->st_rdev = 0; /* not used by Git */
buf->st_atime = filetime_to_time_t(&(fdata.ftLastAccessTime));
buf->st_mtime = filetime_to_time_t(&(fdata.ftLastWriteTime));
buf->st_ctime = filetime_to_time_t(&(fdata.ftCreationTime));
return 0;
}
The assignment of buf->st_ctime doesn’t seem right to me. I understand there’s
no good choice here, but I think a better choice would be to duplicate the
definition used for st_mtime.
Background: When I do a git status on Windows and then later on Ubuntu (or the
other order), it is extremely slow, as the entire tree is being traversed. I
tracked it down to this difference in definition of c_time. Yes, I know about
the core.trustctime variable, but my problem aside this seems like an unwise
choice.
Thanks for listening,
K.
Re: Git on Windows maps creation time onto changed time
> The purpose of these values is to allow to notice a change on the file system > without going through the actual file data. Duplicating st_mtime would be > pointless. Well, I agree with the first statement. I disagree with the 2nd. It’s not pointless to fix a problem, and in theory the creation date of a file can never change. > Don't do that then. Use core.trustctime. I am. Unfortunately, my problem isn’t solved by that alone. Perhaps this deserves its own thread, but on Windows the st_ino field is set to zero. This can also trigger a false positive, causing the whole cache to be rebuilt unnecessarily. K.
Re: Git on Windows maps creation time onto changed time
> On Feb 2, 2018, at 1:18 PM, Johannes Schindelin > wrote: > > You cannot assume that the inode numbers are identical between file > systems/operating systems. That's simply not going to work. Yes, I agree with you, I cannot assume this, so I checked. In my case, the inode numbers are indeed identical. > I know you really want *so hard* for the same working directory to be > accessible from both Windows and Linux. I have a lot of sympathy for that > sentiment. Though I do not see much chance for success on that front. I’m certainly willing to accept that there are going to be limitations by using a filesystem from two different operating systems. But regardless of the problems caused by that pattern, would you agree that the Windows code should be using the actual inode number (well, 32-bits of it) instead of zero? K.
