!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 tandard, 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.) ***************************************************************