X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
X-Recipient: djgpp AT delorie DOT com
X-Original-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net;
	s=badeba3b8450; t=1595695381;
	bh=rJQy9VooAvKgfSgPDQmRHKqvEM2A0JbzXm+Nb900Hqw=;
	h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To;
	b=VFabnRNXKAlvE/Py5MqYz1PM5Sfb7y7Hgs6Tq2ii/3bbvaMOENdwtBEkTHIa6XE8z
	 E1Y6n8drS1hvQBmwHYP8rvjr+bHc2Vj9kLHmSWEKNWfN2LPdQVVT68ePNmpqgoCHo2
	 /KzDgf6ekFfNL0pHoQlv6GSr46xACAYLuzUaevdI=
X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c
Message-ID: <5F1C6113.9050807@gmx.de>
Date: Sat, 25 Jul 2020 18:42:59 +0200
From: "Juan Manuel Guerrero (juan DOT guerrero AT gmx DOT de) [via djgpp AT delorie DOT com]" <djgpp AT delorie DOT com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; de; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Subject: Re: Bug report -- utimes()
References: <CALPW7mRjrRaQO=sC82OAFQJce5NJz4erZc=f=JJfMhDpVHEHNQ AT mail DOT gmail DOT com>
In-Reply-To: <CALPW7mRjrRaQO=sC82OAFQJce5NJz4erZc=f=JJfMhDpVHEHNQ@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
X-Provags-ID: V03:K1:A2P8UgyfSU3AESIAUBGxlZPNEkchEQRVDdqpEeKSkeM582PsIDj
 MgEPJwakPBvSd6Sni5YizgAj/QG/uAjyGjC1M8qst2IVu7US/8uGU4PSaYCVFvO+Gl3Z10r
 YEa15gG79XC0Gm+f2cu+FEt4mQkAwO+CsfRxWlUKjqJ9UyyUUWF9agRBFx47mjqEbq+GbiU
 4eXIRLN4kkA9LhUQTPB/w==
X-Spam-Flag: NO
X-UI-Out-Filterresults: notjunk:1;V03:K0:RbfMFz1o07s=:+kIG1PHn1iWuqZWRGK+HD/
 gPVaVa/EJgG+BVSkdKMfWphvj1PSctUDEYGwblueCbmQtfLw6jZuY6gy+hRFKLdChUmKyBSw4
 C/VpzeRMXSPmh4aAfivz+sRcN9exBfOhmXkGYcvbvdHfaiDeUwPzdhWQ4zafimMqCnppXFMbh
 BSNsK7wIwRKJteFPXbbZ5AOzUUTkrSWWthsyYCDs14k4wBXQpxTAkbncrL8TFg/ALI1T7bVnX
 He0Ko6VE2tc0qNKFSRIf/oBcH2jeJYhEX8z/LHKLeZxjzk5F7hFF4DvS0o/YRwuPgf0eaK4EN
 0TWbPT+gHXwYc/wlplQwGVlUE6O4y35MYqOwDmHmWygUqAPGn7Yl7JkXoGF4BBQUdNhnpcS43
 Z6e7PBwTohAxAqv3REhCx27diybh2yIvWgifMJvnhmTD1LGtX0UCdu22vu6k2nueZl8s2t/o0
 MvFv4+uK8OIfXXgUP3CptxF3ruFAqQWHQYzQFkM0NuO25EmHy3TzBxVCvU7PvtuqvCycUw61Y
 Lo+mVD7aDEE4CjzIqGcvlYxhb2OElmgUX2rvUTmcUAw5XkBWDZ3c1NF3QJyyAr2WBMIzHmzqe
 YcjQUHYavz5J5yc210fgtM8WGgRmvs8HNIiPjDANwHUyi/0SKjMvNoVt5vXBpi6r5h4cvcvKF
 qwG78+VsImOu7AgmHhZd7d4rb2gxVJipndwT3scYBB9NaraYnKH+2IRZI34Mr3jLiTClML4zP
 uO8fvEfUqSwyVYk2eVoy7nKtxI0K/e0hHxA0k7iFQvCDTi5CkRtdd2+1BLxURkAITBQ6BJVBu
 JwQVya7yPlsPZb0h9XiDWXyjQ45SWQ6JRSTbF4nk498YscYDIOkBi/y8uWupRPYdtJQ4gXA/K
 LkfiUwAcm6N5cjdJEKGoo6KMd9VNPEOy/sM126BEOv3Fjh4HWeAq0V487QwEc5347EyVHMbHx
 vyFbWOBWMFXaEPi58JTNGLJNXWtJTg8cdQHljZhWXTBPr/wkULV744Vm3j+hSvxsAilxuhj8e
 H8RYTOkE6rRLoh17CrybU7FnxxG2ZVPxhAfmYR/ulQYrU2Zl0GBqvAgT9/YqTD7OM2ncDd6YV
 UgIeSikMjKGLZ76PqzkQhevgsECh9bC2ePQzYMW4rALCUdyxzEkW6+nj70DUQc7BRgNeir10t
 dte4W87mfOM0czEA2ihuQ+hBwODbQBYFvHUQtPCKa4dAhxADhsfS/QwjG9Og/ElKVy643TaMw
 eF7GaDj7mSYygkpIVA2YAsrE6l7YkOE/BIJJSaA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id 06PGhqEs003417
Reply-To: djgpp AT delorie DOT com

Am 24.07.2020 15:41, schrieb A. Wik (awik32 AT gmail DOT com) [via djgpp AT delorie DOT com]:
> Hi,
>
> Jörg Schilling asked me to file this bug report: "Could you send a bug
> report to DJGPP that utimes() officially has a const struct timestruct
> * parameter?".  By officially, I assume he means a standard like
> POSIX.
>
> Regards,
> Albert.
>


Sorry, but I do not fully understannd this.
DJGPP provides utime() and utimes() that fully conform to 4.3BSD, POSIX.1-2001
with regards to their arguments.  There is nothing like a const struct timestruct
as argument.  Both functions may be regarded as obsolete now a days but MSDOS
is it too.
The only function providing a const struct timestruct as argument, that I am
aware of, are futimens() and utimensat() and they are specified in POSIX.1-2008.
utimensat() and futimens() update the timestamps of a file with nanosecond
precision. This contrasts with the historical utime() and utimes(), which
permit only second and microsecond precision, respectively, when setting file
timestamps.  Of course, on plain DOS and may be on Win95 and Win98, nanosecond
and microsecond update of file timesamps are an illusion and have never been
provided by the OSs AFAIK.  The timestamp granularity is 2 seconds.
The bottom line of all this is that nothing is wrong; in the best case we are
missing a new POSIX function that Jörg Schilling would like to use in his cdrtools.
It may be likely that fake functions could be provided that in the end will
call utime() that will do the job with the MSDOS typical 2 second granularity.
If a DJGPP port of cdrtools, using those fake functions, will really work
as expected on plain DOS will have to be investigated by trial-and-error.


Regards,
Juan M. Guerrero