Re: plans for file related modules on Windows
On Sun, May 14, 2017 at 06:06:03PM +0200, Bruno Haible wrote: > > 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.
Re: plans for file related modules on Windows
Hi Paul, Thanks for the pointers. > 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. 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. > > - 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. > 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
Re: plans for file related modules on Windows
On 05/09/2017 01:34 PM, Bruno Haible wrote: - 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
Re: plans for file related modules on Windows
On Tue, May 09, 2017 at 10:34:04PM +0200, Bruno Haible wrote:
> 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.
plans for file related modules on Windows
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
