Discussion:
Windows same_file macro not reliable/usable when using Visual Stdudio
(too old to reply)
Kees Dekker
2017-02-23 15:03:04 UTC
Permalink
Raw Message
Hi,

I was trying to get diffutils 3.5 working while using Visual Studio. I.e. I like to generate native Windows binaries, that do not need Cygwin.

Based on recommendation in the thread at https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25814, I'm sending a request to you.

Can you please fix the same_file (and same_file_attributes) macros in system.h in such way that they are usable on Windows too?
At default, Microsoft Visual studio runtime does not support inodes (while Cygwin does). The same applies to uid and gid. Either a translation layer
is needed, or the macro need to be changed in a similar (quick and dirty way) like I did:

if _WIN32
# define same_file(s, t) 0
#else
# define same_file(s, t) \
((((s)->st_ino == (t)->st_ino) && ((s)->st_dev == (t)->st_dev)) \
|| same_special_file (s, t))
#endif

and

#ifndef same_file_attributes
#if _WIN32
# define same_file_attributes(s, t) 0
#else
# define same_file_attributes(s, t) \
((s)->st_mode == (t)->st_mode \
&& (s)->st_nlink == (t)->st_nlink \
&& (s)->st_uid == (t)->st_uid \
&& (s)->st_gid == (t)->st_gid \
&& (s)->st_size == (t)->st_size \
&& (s)->st_mtime == (t)->st_mtime \
&& (s)->st_ctime == (t)->st_ctime)
#endif
#endif

Not sure whether this is a very nice fix (I think it isn't), but in the way how Microsoft provides stat/fstat information, there is not much to choose.
I'm in doubt whether this is proposal ok for you, but I really like of gnulib became supported on native Windows/Visual Studio as well.

Regards,
Kees
Paul Eggert
2017-02-23 15:58:39 UTC
Permalink
Raw Message
I'm afraid it doesn't suffice merely to say "here's some code; figure it
out"; we need a patch against Gnulib, something that you've tested. I
suggest using the format of "git format-patch" for the patch, and using
"git send-email" to email the patch to bug-***@gnu.org. You can use
the following commands to get started:

git clone git://git.savannah.gnu.org/gnulib.git

git format-patch -1

This should generate a patch in the sort of format we're looking for. To test your work, run a command like this:

./gnulib-tool --test stat linkat

Substitute the modules you have affected and want to test for "stat linkat".
Kees Dekker
2017-02-23 16:24:04 UTC
Permalink
Raw Message
Post by Paul Eggert
I'm afraid it doesn't suffice merely to say "here's some code; figure it
out"; we need a patch against Gnulib, something that you've tested. I
suggest using the format of "git format-patch" for the patch, and using
I don't have the intention to say 'figure it out', but you already told me that you did
not agree with my proposal. So why then asking to make a git patch?

I don't have the full knowledge and (even more important) the time to make Cygwin
alike inode implementation. So I'm willing to make a git patch for the code I provided,
but not able to make something that let get windows more close to POSIX behavior.
It is almost a design decision to choose to what level Windows should behave like
POSIX systems. It is IMO impossible to tell such changes in a git chang
Paul Eggert
2017-02-23 17:29:14 UTC
Permalink
Raw Message
Post by Kees Dekker
I really like
to know what is wanted here?
As I recall, my suggestion was along the lines of changing Gnulib to
behave the way you like, and/or changing some Gnulib-using GNU
application (I forget which you were interested in) to use Gnulib to
test whether two files are the same. That is, whatever fix is needed, it
should be done for all Gnulib-using programs, not just for the app in
question. My guess is that you're interested in the Gnulib 'same' and/or
'same-inode' modules, or something like that. But since I don't know
exactly what you're looking for and I don't use MS-Windows, it's hard
for me to say precisely what patches you should propose.
Eli Zaretskii
2017-02-26 16:11:56 UTC
Permalink
Raw Message
Date: Thu, 23 Feb 2017 16:24:04 +0000
I don't have the full knowledge and (even more important) the time to make Cygwin
alike inode implementation. So I'm willing to make a git patch for the code I provided,
but not able to make something that let get windows more close to POSIX behavior.
It is almost a design decision to choose to what level Windows should behave like
POSIX systems.
Modern MS-Windows filesystems do have an equivalent of an inode, and
also of uid and gid of the file's owner, but the implementations of
'stat' and 'fstat' in the MS C runtime libraries don't return this
information. It is possible to obtain that information, but it would
require a more-or-less complete replacement of 'stat' and 'fstat', and
also replacement of 'struct stat', because the replacement inode
values are (AFAIR) 48-bit values, whereas the inode field in stock MS
'struct stat' is just 16-bit wide.

An example of such a replacement can be found in the Emacs sources.

A simpler solution would be to return zero from same_file if both
files have inode values of zero. I think such values are impossible
on Posix systems, but if they are, then this could be a Windows
specific definition of the macro (system.h in Diffutils is already
prepared to support a build which defines a non-default macro).

There's no such easy solution for same_file_attributes, but AFAICT
that macro is only called by Diffutils if same_file returns non-zero,
so taking care of the latter will also resolve the problem with the
former.

HTH
Kees Dekker
2017-02-27 07:38:38 UTC
Permalink
Raw Message
Post by Eli Zaretskii
A simpler solution would be to return zero from same_file if both
files have inode values of zero. I think such values are impossible
on Posix systems, but if they are, then this could be a Windows
specific definition of the macro (system.h in Diffutils is already
prepared to support a build which defines a non-default macro).
There's no such easy solution for same_file_attributes, but AFAICT
that macro is only called by Diffutils if same_file returns non-zero,
so taking care of the latter will also resolve the problem with the
former.
That's exactly what I did. If I have time, I will try to create (for me for the first time) a gitthub change (it is on my TODO list), but it will take time.
Loading...