Version 1.2 of acs/ac-00301.txt

Unformatted version of acs/ac-00301.txt version 1.2
Other versions for file acs/ac-00301.txt

!standard A.16(27/2)          18-01-11 AC95-00301/00
!class Amendment 18-01-11
!status received no action 18-01-11
!status received 17-12-05
!subject Proposal for Ada.Directories
!summary
!appendix

!topic Proposal for Ada.Directories, Ada 202x
!reference Ada 202x 2012 RMA.16
!from Gautier de Montmollin 17-12-05
!keywords Ada.Directories Set_Modification_Time Read_Only Set_Read_Only
!discussion

Here is a couple of proposals for Ada.Directories.

1) After the informational functions in 24/2 .. 27/2 (Exists, Kind, Size,
Modification_Time), the following would be very useful

   function Read_Only (Name : in String) return Boolean;

It is often better to know, if the file exists (first checked with Exists),
whether you can erase it or rewrite it or not, instead of doing so via trial
and error (well, exception...).

2) In order to restore a file from a database or an archive file in a portable
way, it would be useful to be able to restore its modification time and the
read-only attribute.

   procedure Set_Modification_Time (Name : in String; Restored : Ada.Calendar.Time);
   procedure Set_Read_Only (Name : in String; State : Boolean);

Notes:
- the ability to set the read-only attribute has a broader usefulness.
- in GNAT's System, System.OS_Lib has already:
  Set_File_Last_Modify_Time_Stamp
  Set_Read_Only

***************************************************************

From: Martin Dowie
Sent: Tuesday, December 5, 2017  3:45 AM

1) is a race condition...you always have to handle a file not being what you
just checked for.

All these subprograms would still be useful additions though.

***************************************************************

From: Randy Brukardt
Sent: Tuesday, December 5, 2017  3:46 PM

>	Here is a couple of proposals for Ada.Directories.

Ada.Directories was intended to be a least-common-demonator package; we
considered many other operations but concluded that they were not present
often enough to put them into Ada.Directories. Implementations are supposed
to provide child packages with additional operations that make sense for
their targets.

>	1) After the informational functions in 24/2 .. 27/2 (Exists, Kind,
>       Size, Modification_Time), the following would be very useful
>
>	   function Read_Only (Name : in String) return Boolean;
>
>	It is often better to know, if the file exists (first checked with
>Exists), whether you can erase it or rewrite it or not, instead of
>doing so via trial and error (well, exception...).

(1) Someone noted that all such queries are race conditions. You have to
handle the exceptions in any case, so there is almost no value to querying
ahead of time. (Exists is intended mainly to be used when the file is NOT
going to be opened.)
(2) Such a function is highly target-specific. The description you gave above
matches the Windows semantics exactly, but Linux had much more nuance -- in
particular, whether a file can be "erased" depends on the containing directory,
not the file's own permissions. Thus, the function would almost certainly
implemented differently on different targets, meaning the information could not
be usefully relied on (at least not in edge cases like whether the file can be
erased).
(3) Informational features are found in Ada.Directories.Information. This
package should be provided with every Ada implementation, and in the particular
cases of Windows and Linux, the AARM specifies a minimum set of operations that
should be found in the package. (We can't mention Windows or Linux in the
Standard, or this would all have been normative requirements.) Implementations
that don't follow this advice is ignoring the clear intent of the designers.
For Windows, Ada.Information.Is_Read_Only is the operation that you want. If
your compiler doesn't support that, complain to your vendor (not the ARG!!!!).

>2) In order to restore a file from a database or an archive file in a
>portable way, it would be useful to be able to restore its modification time
>and the read-only attribute.
>
>	   procedure Set_Modification_Time (Name : in String; Restored : Ada.Calendar.Time);
>	   procedure Set_Read_Only (Name : in String; State : Boolean);

Implementations are expected to provide such operations, if they make sense
for the target, in another child of Ada.Directories. (We didn't specify the name
or form as setting seemed much too complex to specify.) In any case, one cannot
use just these two operations to restore a file; you have to restore all of the
permissions and time stamps (Windows has 3 time stamps).
And again, the meaning (especially the meaning of Set_Read_Only) is very
target-specific. It's very unlikely that any two Ada vendors would end up with
the same implementation (unless they literally copied someone else's
implementation), so code using it would not be portable on the margins. (For
instance, precisely what Linux permissions does this set? There are many
choices.)

Because these operations (and many others) are so target-specific, it seems
better to provide them in the target-specific packages. We could try to beef
up the rules so that implementers have a harder time ignoring/absuing them,
and perhaps add a set of setter packages, but I don't think it makes sense to
go further. (Especially as the specific set of operations in Ada.Directories
will never be clear cut. Why should Is_Read_Only and Set_Read_Only be added,
but not Creation_Time/Set_Creation_Time? And so on. We could waste hours of
valuable time rearguing questions that we argued back in 2002.)

***************************************************************

Questions? Ask the ACAA Technical Agent