plans for file related modules on Windows

[Bruno Haible]

Hi,

It's clear that different gnulib users need different levels of native Windows
support. Some will want to avoid 'struct stat', some will want to use the ino_t
values in struct stat.

Here's my current plan: Introduce a set of orthogonal, transversal modules.
("transversal" in the sense that such a module does not provide a function,
but rather provides guarantees for other modules.)

- windows-year2038 : define time_t as 64-bit (might involve renaming module time to time-h)
- windows-symlinks : add symlink support to stat, lstat, readlink etc.
- windows-stat-timespec : add 100ns resolution to file times
- windows-stat-inodes : redefine dev_t, ino_t
- windows-uid : redefine uid_t [1]
- windows-gid : redefine gid_t [1]
- windows-utf8-filenames : implies override of all file-related functions
- largefile : support for files > 2 GB (already partially implemented in 2012)

An override of 'struct stat' will be necessary for windows-year2038,
windows-stat-timespec, windows-stat-inodes, windows-uid, windows-gid, largefile.

What do you think about it?

Which of these modules would you like to see implemented first?

Bruno

[1] as proposed by Bastien Roucariès
https://lists.gnu.org/archive/html/bug-gnulib/2011-09/msg00130.html

[Ben Pfaff]

Post by Bruno Haible
It's clear that different gnulib users need different levels of native Windows
support. Some will want to avoid 'struct stat', some will want to use the ino_t
values in struct stat.
Here's my current plan: Introduce a set of orthogonal, transversal modules.
("transversal" in the sense that such a module does not provide a function,
but rather provides guarantees for other modules.)
- windows-year2038 : define time_t as 64-bit (might involve renaming module time to time-h)
- windows-symlinks : add symlink support to stat, lstat, readlink etc.
- windows-stat-timespec : add 100ns resolution to file times
- windows-stat-inodes : redefine dev_t, ino_t
- windows-uid : redefine uid_t [1]
- windows-gid : redefine gid_t [1]
- windows-utf8-filenames : implies override of all file-related functions
- largefile : support for files > 2 GB (already partially implemented in 2012)
An override of 'struct stat' will be necessary for windows-year2038,
windows-stat-timespec, windows-stat-inodes, windows-uid, windows-gid, largefile.
What do you think about it?
Which of these modules would you like to see implemented first?

I did not realize that Windows could even support a proper
implementation of the struct stat st_dev and st_ino. I'd find this
useful in multiple programs, although in some of them I might really
just use the code you write as an educational resource.

[Bruno Haible]

Hi Ben,

Post by Ben Pfaff
I did not realize that Windows could even support a proper
implementation of the struct stat st_dev and st_ino. I'd find this
useful in multiple programs, although in some of them I might really
just use the code you write as an educational resource.

I've considered your wish. This functionality is now implemented as
module 'windows-stat-inodes'.

Bruno

[Ben Pfaff]

Post by Bruno Haible

Post by Ben Pfaff
I did not realize that Windows could even support a proper
implementation of the struct stat st_dev and st_ino. I'd find this
useful in multiple programs, although in some of them I might really
just use the code you write as an educational resource.

I've considered your wish. This functionality is now implemented as
module 'windows-stat-inodes'.

Thank you! I learned a lot of useful information from reading the
module, and in addition I do expect to use the module directly.

[Paul Eggert]

Post by Bruno Haible
- windows-year2038 : define time_t as 64-bit (might involve renaming module time to time-h)

Such a module could be useful on non-MS-Windows platforms too. The
module could support functions like localtime even on 32-bit platforms
that can't handle time stamps past 2038. (It'd have trouble with
functions like 'stat', of course.) This would be useful on GNU/Linux
x86, for example. It'd be a no-op on platforms like recent OpenBSD x86,
which already uses 64-bit time_t. A similar point applies to some of the
other modules you mentioned, e.g., windows-uid. So perhaps these modules
should not have "windows-" in their names.


Simon Josefsson proposed something along these lines a decade ago:

https://lists.gnu.org/archive/html/bug-gnulib/2007-03/msg00106.html

The project is somewhat more urgent now than it was back then.


Also please see plans in time_t area in the Linux kernel and in glibc,
summarized here:

https://lwn.net/Articles/643234/
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

[Bruno Haible]

Hi Paul,

Thanks for the pointers.

Post by Paul Eggert
https://lists.gnu.org/archive/html/bug-gnulib/2007-03/msg00106.html
The project is somewhat more urgent now than it was back then.

I tend to agree by now. Linux/x86 will be occupying a niche market (maybe 1%)
in 20 years; but if only 1% of electronic devices stop working in 2038, it
would be a major mess. And you can expect that some devices that are being
sold today will still be in use in 21 years: my last washing machine operated
for 24 years.

Post by Paul Eggert

Post by Bruno Haible
- windows-year2038 : define time_t as 64-bit (might involve renaming module time to time-h)

Such a module could be useful on non-MS-Windows platforms too. The
module could support functions like localtime even on 32-bit platforms
that can't handle time stamps past 2038. (It'd have trouble with
functions like 'stat', of course.) ...
https://sourceware.org/glibc/wiki/Y2038ProofnessDesign

Indeed, once glibc will have this support, it makes sense to have a gnulib
that turns it on. => I agree, it should be named 'year2038'.

Until that happens, however, i.e. while time() and stat() behave in
unpredictable ways, it does not make sense IMO to put effort into
making localtime() work right.

Post by Paul Eggert
A similar point applies to some of the other modules you mentioned,
e.g., windows-uid.

What do you mean? Is uid_t being replaced by a larger type on some platforms?

Bruno

[Paul Eggert]

Post by Bruno Haible
Is uid_t being replaced by a larger type on some platforms?

I was thinking more about a long-ago change where it grew from 16 to 32
bits on some platforms. On second thought this is probably not worth
worrying about nowadays, and probably wasn't doable even way back then.