From: David Michael <hidden> Date: 2016-06-15 23:03:08
This adds simple wrapper functions around calls to stat(), fstat(),
and lstat() that translate the operating system's native file type
bits to those used by most operating systems. It also rewrites the
S_IF* macros to the common values, so all file type processing is
performed using the translated modes. This makes projects portable
across operating systems that use different file type definitions.
Only the file type bits may be affected by these compatibility
functions; the file permission bits are assumed to be 07777 and are
passed through unchanged.
Signed-off-by: David Michael <redacted>
---
Hi,
This is my most recent attempt at solving the problem of z/OS using
different file type values than every other OS. I believe it should be
safe as long as the file type bits don't ever need to be converted back
to their native values (and I didn't see any instances of that).
I've been testing it by making commits to the same repositories on
different operating systems and pushing those changes around, and so far
there have been no issues.
Can anyone foresee any problems with this method?
Thanks.
David
Makefile | 8 ++++++++
cache.h | 7 -------
compat/stat.c | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
configure.ac | 22 ++++++++++++++++++++++
git-compat-util.h | 32 ++++++++++++++++++++++++++++++++
5 files changed, 111 insertions(+), 7 deletions(-)
create mode 100644 compat/stat.c
@@ -191,6 +191,10 @@ all::# Define NO_TRUSTABLE_FILEMODE if your filesystem may claim to support# the executable mode bit, but doesn't really do so.#+# Define NEEDS_MODE_TRANSLATION if your OS strays from the typical file type+# bits in mode values (e.g. z/OS defines I_SFMT to 0xFF000000 as opposed to the+# usual 0xF000).+## Define NO_IPV6 if you lack IPv6 support and getaddrinfo().## Define NO_UNIX_SOCKETS if your system does not offer unix sockets.
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
if (S_ISBLK(native_mode))
return 0060000 | perm_bits;
if (S_ISCHR(native_mode))
return 0020000 | perm_bits;
if (S_ISFIFO(native_mode))
return 0010000 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
From: David Michael <hidden> Date: 2016-06-15 23:03:09
On Sun, Nov 30, 2014 at 3:16 PM, Torsten Bögershausen [off-list ref] wrote:
[snip]
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
if (S_ISBLK(native_mode))
return 0060000 | perm_bits;
if (S_ISCHR(native_mode))
return 0020000 | perm_bits;
if (S_ISFIFO(native_mode))
return 0010000 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
Sure, I can send an updated patch with the new variable and without the "else"s.
Regarding the question in the last comment: I was assuming if this
case was ever reached, Git would handle the returned mode the same way
as if it encountered an unknown/non-standard file type on a normal
operating system, which could die() if needed in the function that
called stat().
Should I send an updated patch that die()s there?
David
On Sun, Nov 30, 2014 at 3:16 PM, Torsten Bögershausen [off-list ref] wrote:
[snip]
quoted
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
if (S_ISBLK(native_mode))
return 0060000 | perm_bits;
if (S_ISCHR(native_mode))
return 0020000 | perm_bits;
if (S_ISFIFO(native_mode))
return 0010000 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
Sure, I can send an updated patch with the new variable and without the "else"s.
Regarding the question in the last comment: I was assuming if this
case was ever reached, Git would handle the returned mode the same way
as if it encountered an unknown/non-standard file type on a normal
operating system, which could die() if needed in the function that
called stat().
Should I send an updated patch that die()s there?
David
Not yet, please wait with a V2 patch until I finished my thinking ;-)
I take back the suggestion with the die(). I was thinking how to handle
unforeseen types, which may show up on the z/OS some day,
So die() is not a good idea, it is better to ignore them, what the code
does.
Knowing that Git does not track block devices, nor character devices nor sockets,
the above code could be simplyfied even more, by mapping everything which
is not a directory, a file or a softlink to "device type 0)
This is just a suggestion, I want to here from others as well:
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
/* Git does not track S_IFCHR, S_IFBLK, S_IFIFO, S_IFSOCK */
return perm_bits;
From: David Michael <hidden> Date: 2016-06-15 23:03:09
On Mon, Dec 1, 2014 at 12:55 AM, Torsten Bögershausen [off-list ref] wrote:
On 12/01/2014 04:40 AM, David Michael wrote:
quoted
On Sun, Nov 30, 2014 at 3:16 PM, Torsten Bögershausen [off-list ref]
wrote:
[snip]
quoted
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
if (S_ISBLK(native_mode))
return 0060000 | perm_bits;
if (S_ISCHR(native_mode))
return 0020000 | perm_bits;
if (S_ISFIFO(native_mode))
return 0010000 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
Sure, I can send an updated patch with the new variable and without the
"else"s.
Regarding the question in the last comment: I was assuming if this
case was ever reached, Git would handle the returned mode the same way
as if it encountered an unknown/non-standard file type on a normal
operating system, which could die() if needed in the function that
called stat().
Should I send an updated patch that die()s there?
David
Not yet, please wait with a V2 patch until I finished my thinking ;-)
I take back the suggestion with the die(). I was thinking how to handle
unforeseen types, which may show up on the z/OS some day,
So die() is not a good idea, it is better to ignore them, what the code
does.
Knowing that Git does not track block devices, nor character devices nor
sockets,
the above code could be simplyfied even more, by mapping everything which
is not a directory, a file or a softlink to "device type 0)
This is just a suggestion, I want to here from others as well:
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
/* Git does not track S_IFCHR, S_IFBLK, S_IFIFO, S_IFSOCK */
return perm_bits;
I had considered omitting those three as well at first, but in this
case it would mean that they will be unusable all together.
The z/OS S_IFMT definition (i.e. the file type bit mask) is
0xFF000000, and the common/translated S_IFMT definition is 0xF000.
Since the S_ISxxx macros use the typical ((mode & S_IFMT) == S_IFxxx)
definition, they would never match a native z/OS mode after redefining
S_IFMT.
So translating those types isn't just for tracking files, it's to
support any use of S_ISxxx anywhere in the code. It should be okay to
remove any of those types if we know that Git will never need to use
them.
David
From: David Michael <hidden> Date: 2016-06-15 23:03:09
On Mon, Dec 1, 2014 at 7:48 AM, David Michael [off-list ref] wrote:
On Mon, Dec 1, 2014 at 12:55 AM, Torsten Bögershausen [off-list ref] wrote:
quoted
On 12/01/2014 04:40 AM, David Michael wrote:
quoted
On Sun, Nov 30, 2014 at 3:16 PM, Torsten Bögershausen [off-list ref]
wrote:
[snip]
quoted
Could the code be more human-readable ?
static inline mode_t mode_native_to_git(mode_t native_mode)
{
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
if (S_ISBLK(native_mode))
return 0060000 | perm_bits;
if (S_ISCHR(native_mode))
return 0020000 | perm_bits;
if (S_ISFIFO(native_mode))
return 0010000 | perm_bits;
/* Non-standard type bits were given. */
/* Shouldn't we die() here ?? */
return perm_bits;
}
Sure, I can send an updated patch with the new variable and without the
"else"s.
Regarding the question in the last comment: I was assuming if this
case was ever reached, Git would handle the returned mode the same way
as if it encountered an unknown/non-standard file type on a normal
operating system, which could die() if needed in the function that
called stat().
Should I send an updated patch that die()s there?
David
Not yet, please wait with a V2 patch until I finished my thinking ;-)
I take back the suggestion with the die(). I was thinking how to handle
unforeseen types, which may show up on the z/OS some day,
So die() is not a good idea, it is better to ignore them, what the code
does.
Knowing that Git does not track block devices, nor character devices nor
sockets,
the above code could be simplyfied even more, by mapping everything which
is not a directory, a file or a softlink to "device type 0)
This is just a suggestion, I want to here from others as well:
int perm_bits = native_mode & 07777;
if (S_ISREG(native_mode))
return 0100000 | perm_bits;
if (S_ISDIR(native_mode))
return 0040000 | perm_bits;
if (S_ISLNK(native_mode))
return 0120000 | perm_bits;
/* Git does not track S_IFCHR, S_IFBLK, S_IFIFO, S_IFSOCK */
return perm_bits;
I had considered omitting those three as well at first, but in this
case it would mean that they will be unusable all together.
The z/OS S_IFMT definition (i.e. the file type bit mask) is
0xFF000000, and the common/translated S_IFMT definition is 0xF000.
Since the S_ISxxx macros use the typical ((mode & S_IFMT) == S_IFxxx)
definition, they would never match a native z/OS mode after redefining
S_IFMT.
So translating those types isn't just for tracking files, it's to
support any use of S_ISxxx anywhere in the code. It should be okay to
remove any of those types if we know that Git will never need to use
them.
Apologies, in my pre-coffee reply, I confused myself into thinking the
omitted types were going to be returned unchanged as opposed to being
changed to zero. That second paragraph is irrelevant.
But regarding the last paragraph: a quick grep for instances of using
those file types in the Git source found S_ISFIFO and S_ISSOCK in
git.c.
I just noticed that I copied the list of standard file type macros
from SUSv2, and S_IFSOCK was added after that. z/OS does implement
S_IFSOCK, so I think I should add it to the v2 patch to support the
test in git.c.
Another grep found no instances of testing for block or character
devices, so it should be okay to remove those from the patch if Git is
unlikely to use them in the future (unless we just want to provide all
7 types from http://pubs.opengroup.org/onlinepubs/009695399/basedefs/sys/stat.h.html
).
David
From: David Michael <hidden> Date: 2016-06-15 23:03:09
On Mon, Dec 1, 2014 at 9:44 AM, Duy Nguyen [off-list ref] wrote:
On Sun, Nov 30, 2014 at 9:41 AM, David Michael [off-list ref] wrote:
quoted
+int git_stat(const char *path, struct stat *buf)
+{
+ int rc;
+ rc = stat(path, buf);
+ if (buf != NULL)
It's a minor thing, but maybe test "!rc" instead of "buf != NULL"?
Okay, it makes sense to only do the conversion for a successful return code.
Should it test for both a zero return code and a non-null pointer? I
don't know if there are any cases where passing a null pointer is
legal. The standard doesn't seem to explicitly forbid it. z/OS
returns -1 and sets errno to EFAULT when stat() is given NULL, but
this patch should be able to be used on any platform.
David