* Ada.Directories.Copy_File behavior @ 2011-02-19 22:37 tmoran 2011-02-19 23:01 ` Vinzent Hoefler 2011-02-26 2:34 ` Randy Brukardt 0 siblings, 2 replies; 15+ messages in thread From: tmoran @ 2011-02-19 22:37 UTC (permalink / raw) If the Target_Name file already exists, does Copy_File raise an exception, or does it replace the old file? I can't seem to find where the behavior is specified in the ARM. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-19 22:37 Ada.Directories.Copy_File behavior tmoran @ 2011-02-19 23:01 ` Vinzent Hoefler 2011-02-20 0:01 ` tmoran 2011-02-21 18:05 ` Adam Beneschan 2011-02-26 2:34 ` Randy Brukardt 1 sibling, 2 replies; 15+ messages in thread From: Vinzent Hoefler @ 2011-02-19 23:01 UTC (permalink / raw) wrote: > If the Target_Name file already exists, does Copy_File raise an exception, > or does it replace the old file? I can't seem to find where the behavior > is specified in the ARM. |The exception Use_Error is propagated if the external environment does not |support creating the file with the name given by Target_Name So, the actual behaviour depends on the underlying OS, I'd say. Vinzent. -- You know, we're sitting on four million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it? -- Rockhound, "Armageddon" ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-19 23:01 ` Vinzent Hoefler @ 2011-02-20 0:01 ` tmoran 2011-02-20 0:31 ` Vinzent Hoefler 2011-02-20 11:01 ` Martin 2011-02-21 18:05 ` Adam Beneschan 1 sibling, 2 replies; 15+ messages in thread From: tmoran @ 2011-02-20 0:01 UTC (permalink / raw) > So, the actual behaviour depends on the underlying OS, I'd say. The Windows CopyFile function takes a BOOL parameter bFailIfExists, so is it implementation-defined what Ada.Directories.Copy_File does? That's not very satisfactory. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-20 0:01 ` tmoran @ 2011-02-20 0:31 ` Vinzent Hoefler 2011-02-20 11:01 ` Martin 1 sibling, 0 replies; 15+ messages in thread From: Vinzent Hoefler @ 2011-02-20 0:31 UTC (permalink / raw) wrote: >> So, the actual behaviour depends on the underlying OS, I'd say. > The Windows CopyFile function takes a BOOL parameter bFailIfExists, > so is it implementation-defined what Ada.Directories.Copy_File does? I'm afraid so. Vinzent. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-20 0:01 ` tmoran 2011-02-20 0:31 ` Vinzent Hoefler @ 2011-02-20 11:01 ` Martin 2011-02-20 20:19 ` tmoran 1 sibling, 1 reply; 15+ messages in thread From: Martin @ 2011-02-20 11:01 UTC (permalink / raw) On Feb 20, 12:01 am, tmo...@acm.org wrote: > > So, the actual behaviour depends on the underlying OS, I'd say. > > The Windows CopyFile function takes a BOOL parameter bFailIfExists, > so is it implementation-defined what Ada.Directories.Copy_File does? > That's not very satisfactory. But I think it's imp-def even without that BOOL. In practise how many OS are you going to support? You may find that they the imp-def is the same for each, so you have a de facto 'standard' behaviour that you don't need to worry about any other special cases for. -- Martin ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-20 11:01 ` Martin @ 2011-02-20 20:19 ` tmoran 2011-02-20 20:25 ` Vinzent Hoefler 0 siblings, 1 reply; 15+ messages in thread From: tmoran @ 2011-02-20 20:19 UTC (permalink / raw) > > The Windows CopyFile function takes a BOOL parameter bFailIfExists, > > so is it implementation-defined what Ada.Directories.Copy_File does? > > That's not very satisfactory. > > But I think it's imp-def even without that BOOL. > > In practise how many OS are you going to support? You may find that No, it's how many *compilers* for a single OS are you going to support? The behavior of Delete_File when the file is already gone, is specified, so failing to specify the behavior for Copy_File looks like a straight-forward oversight. Regarding Delete_File, I wish they had included a "Make_Gone" that would delete the file, or do nothing if it's already gone. I prefer coding to accomplish a certain end, rather than to execute a certain task. It's also unpleasant to either litter code with begin Ada.Directories.Delete_File(X); exception when Ada.Directories.Name_Error => null; end; or to make my own package My_Improved_Ada_Directories ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-20 20:19 ` tmoran @ 2011-02-20 20:25 ` Vinzent Hoefler 0 siblings, 0 replies; 15+ messages in thread From: Vinzent Hoefler @ 2011-02-20 20:25 UTC (permalink / raw) wrote: >> > The Windows CopyFile function takes a BOOL parameter bFailIfExists, >> > so is it implementation-defined what Ada.Directories.Copy_File does? >> > That's not very satisfactory. >> >> But I think it's imp-def even without that BOOL. >> >> In practise how many OS are you going to support? You may find that > > No, it's how many *compilers* for a single OS are you going to support? Well, how many Ada05 compilers are there? And well, looking at GNAT's code, it seems, it overwrites any existing file, so assuming "if in doubt, GNAT is the ARM", Copy_File shall have overwriting semantics. ;) Vinzent. -- You know, we're sitting on four million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it? -- Rockhound, "Armageddon" ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-19 23:01 ` Vinzent Hoefler 2011-02-20 0:01 ` tmoran @ 2011-02-21 18:05 ` Adam Beneschan 2011-02-21 19:26 ` Vinzent Hoefler 2011-02-26 2:41 ` Randy Brukardt 1 sibling, 2 replies; 15+ messages in thread From: Adam Beneschan @ 2011-02-21 18:05 UTC (permalink / raw) On Feb 19, 3:01 pm, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote: > wrote: > > If the Target_Name file already exists, does Copy_File raise an exception, > > or does it replace the old file? I can't seem to find where the behavior > > is specified in the ARM. > > |The exception Use_Error is propagated if the external environment does not > |support creating the file with the name given by Target_Name > > So, the actual behaviour depends on the underlying OS, I'd say. Note that the phrase you quote says "does not support creating". Which is basically the same as the language used in the description of Create operations (see A.8.2(5)). The language does *not* say "does not support copying to" or anything of that sort. So I think Copy_File is supposed to work any time Create will work, including when the file already exists (assuming the permissions are such that the file can be overwritten). And, barring permission/ownership issues, Create normally does not raise an exception if you give it the name of an existing file. In other words, the answer to the OP's question is that it replaces the existing file, if it can. There are still some implementation dependencies with regard to existing files that are marked as read- only or "do-not-delete" or owned by some other user, which I think apply to both Create and Copy_File. If the OS has a "copy file" operation that does not allow an existing file as the target, then Ada.Directories has to work around that, perhaps by checking for an existing file first and deleting it. That's how I interpret the RM, but (disclaimer) I'm not an ARG member and am not really an authority. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-21 18:05 ` Adam Beneschan @ 2011-02-21 19:26 ` Vinzent Hoefler 2011-02-21 19:41 ` Adam Beneschan 2011-02-26 2:41 ` Randy Brukardt 1 sibling, 1 reply; 15+ messages in thread From: Vinzent Hoefler @ 2011-02-21 19:26 UTC (permalink / raw) Adam Beneschan wrote: > On Feb 19, 3:01 pm, "Vinzent Hoefler" > <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote: >> wrote: >> > If the Target_Name file already exists, does Copy_File raise an exception, >> > or does it replace the old file? I can't seem to find where the behavior >> > is specified in the ARM. >> >> |The exception Use_Error is propagated if the external environment does not >> |support creating the file with the name given by Target_Name >> >> So, the actual behaviour depends on the underlying OS, I'd say. > > Note that the phrase you quote says "does not support creating". > Which is basically the same as the language used in the description of > Create operations (see A.8.2(5)). The language does *not* say "does > not support copying to" or anything of that sort. So I think > Copy_File is supposed to work any time Create will work, So far I'm inclined to agree 100%. > including > when the file already exists (assuming the permissions are such that > the file can be overwritten). And, barring permission/ownership > issues, Create normally does not raise an exception if you give it the > name of an existing file. But is that specified anywhere in the ARM? Always being pessimistic, I would read |The exception Use_Error is propagated if, for the specified mode, the |external environment does not support creation of an external file with |the given name (in the absence of Name_Error) and form. as "it is permissible that file creation fails in some environments if a file with the same name already exists". Although one (including me) may consider such an interpretation unlikely, it seems still possible. ;) Vinzent. -- You know, we're sitting on four million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it? -- Rockhound, "Armageddon" ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-21 19:26 ` Vinzent Hoefler @ 2011-02-21 19:41 ` Adam Beneschan 2011-02-21 20:42 ` Vinzent Hoefler 0 siblings, 1 reply; 15+ messages in thread From: Adam Beneschan @ 2011-02-21 19:41 UTC (permalink / raw) On Feb 21, 11:26 am, "Vinzent Hoefler" <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote: > Adam Beneschan wrote: > > On Feb 19, 3:01 pm, "Vinzent Hoefler" > > <0439279208b62c95f1880bf0f8776...@t-domaingrabbing.de> wrote: > >> wrote: > >> > If the Target_Name file already exists, does Copy_File raise an exception, > >> > or does it replace the old file? I can't seem to find where the behavior > >> > is specified in the ARM. > > >> |The exception Use_Error is propagated if the external environment does not > >> |support creating the file with the name given by Target_Name > > >> So, the actual behaviour depends on the underlying OS, I'd say. > > > Note that the phrase you quote says "does not support creating". > > Which is basically the same as the language used in the description of > > Create operations (see A.8.2(5)). The language does *not* say "does > > not support copying to" or anything of that sort. So I think > > Copy_File is supposed to work any time Create will work, > > So far I'm inclined to agree 100%. > > > including > > when the file already exists (assuming the permissions are such that > > the file can be overwritten). And, barring permission/ownership > > issues, Create normally does not raise an exception if you give it the > > name of an existing file. > > But is that specified anywhere in the ARM? Always being pessimistic, I > would read > > |The exception Use_Error is propagated if, for the specified mode, the > |external environment does not support creation of an external file with > |the given name (in the absence of Name_Error) and form. > > as "it is permissible that file creation fails in some environments if a > file with the same name already exists". Although one (including me) may > consider such an interpretation unlikely, it seems still possible. ;) My interpretation is that if the OS allows you to delete a file and then create a new one with the same name, then it does support "creation of an external file with the given name". That's true even if the operation that the OS provides to create a file will return an error if the file already exists. There's nothing in the RM language that says that the OS has to support creating the new file with just one OS call. If the OS won't let you delete a file at all, then it makes sense for the Create procedure to raise an exception (and similarly Copy_File). -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-21 19:41 ` Adam Beneschan @ 2011-02-21 20:42 ` Vinzent Hoefler 0 siblings, 0 replies; 15+ messages in thread From: Vinzent Hoefler @ 2011-02-21 20:42 UTC (permalink / raw) Adam Beneschan wrote: > If the OS won't let you delete a file at all, then it makes sense for > the Create procedure to raise an exception (and similarly Copy_File). Well, I know at least one file system where that would be the case. Not in the usual consumer OS, though. Vinzent. -- You know, we're sitting on four million pounds of fuel, one nuclear weapon, and a thing that has 270,000 moving parts built by the lowest bidder. Makes you feel good, doesn't it? -- Rockhound, "Armageddon" ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-21 18:05 ` Adam Beneschan 2011-02-21 19:26 ` Vinzent Hoefler @ 2011-02-26 2:41 ` Randy Brukardt 2011-02-26 3:22 ` Adam Beneschan 1 sibling, 1 reply; 15+ messages in thread From: Randy Brukardt @ 2011-02-26 2:41 UTC (permalink / raw) "Adam Beneschan" <adam@irvine.com> wrote in message news:ae2a8159-1306-44a3-8283-faa61ec45a01@o21g2000prn.googlegroups.com... ... >That's how I interpret the RM, but (disclaimer) I'm not an ARG member >and am not really an authority. I wrote my previous reply before reading the rest of the thread. I assumed that someone else (especially Adam, who usually is a stickler for such things) had already provided the right answer. I feel better that I didn't remember it after seeing that no one else even found it! Note that A.16(123/2) is a "shall" rule; there is nothing optional about it. Why we didn't just put it into the description of Copy_File isn't clear, but the rule surely exists. The AARM provides a reason for the rule: "This means that Copy_File will copy any file that the Ada programmer could copy (by writing some possibly complicated Ada code)." Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-26 2:41 ` Randy Brukardt @ 2011-02-26 3:22 ` Adam Beneschan 2011-03-01 3:17 ` Randy Brukardt 0 siblings, 1 reply; 15+ messages in thread From: Adam Beneschan @ 2011-02-26 3:22 UTC (permalink / raw) On Feb 25, 6:41 pm, "Randy Brukardt" <ra...@rrsoftware.com> wrote: > "Adam Beneschan" <a...@irvine.com> wrote in message > > news:ae2a8159-1306-44a3-8283-faa61ec45a01@o21g2000prn.googlegroups.com... > ... > > >That's how I interpret the RM, but (disclaimer) I'm not an ARG member > >and am not really an authority. > > I wrote my previous reply before reading the rest of the thread. I assumed > that someone else (especially Adam, who usually is a stickler for such > things) had already provided the right answer. I feel better that I didn't > remember it after seeing that no one else even found it! > > Note that A.16(123/2) is a "shall" rule; there is nothing optional about it. > Why we didn't just put it into the description of Copy_File isn't clear, but > the rule surely exists. That should be A.16(122/2) (at least according to the version I'm looking at, in http://www.ada-auth.org/standards/12aarm/html/AA-A-16.html). I didn't think to look in the "Implementation Requirements". That would have saved a lot of trouble. -- Adam ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-26 3:22 ` Adam Beneschan @ 2011-03-01 3:17 ` Randy Brukardt 0 siblings, 0 replies; 15+ messages in thread From: Randy Brukardt @ 2011-03-01 3:17 UTC (permalink / raw) "Adam Beneschan" <adam@irvine.com> wrote in message news:22503b43-0504-423d-88a0-1c2cdbd8ca79@w9g2000prg.googlegroups.com... >> Note that A.16(123/2) is a "shall" rule; there is nothing optional about >> it. >> Why we didn't just put it into the description of Copy_File isn't clear, >> but >> the rule surely exists. > >That should be A.16(122/2) (at least according to the version I'm >looking at, in >http://www.ada-auth.org/standards/12aarm/html/AA-A-16.html). There is a bug in the paragraph numbers of that draft. There is a reason that it is called a "draft"! I got the correct paragraph number from the printed version of the Ada 2005 RM. Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
* Re: Ada.Directories.Copy_File behavior 2011-02-19 22:37 Ada.Directories.Copy_File behavior tmoran 2011-02-19 23:01 ` Vinzent Hoefler @ 2011-02-26 2:34 ` Randy Brukardt 1 sibling, 0 replies; 15+ messages in thread From: Randy Brukardt @ 2011-02-26 2:34 UTC (permalink / raw) <tmoran@acm.org> wrote in message news:ijpgnh$ec8$1@speranza.aioe.org... > If the Target_Name file already exists, does Copy_File raise an exception, > or does it replace the old file? I can't seem to find where the behavior > is specified in the ARM. The Janus/Ada implementation of Ada.Directories has the following change note: Corrected Copy_File to overwrite existing files, as A.16(123/2) makes it clear that it should work the same as Create (which can overwrite existing files). which points to the paragraph that answers your question. (Which is another way of saying that I didn't remember the answer to this until I happened across that note. And that is annoying since this package was originally my design and mostly was worded by me. Sad to think I've already forgotten about it...I fear my wetware needs a RAM upgrade!) Randy. ^ permalink raw reply [flat|nested] 15+ messages in thread
end of thread, other threads:[~2011-03-01 3:17 UTC | newest] Thread overview: 15+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2011-02-19 22:37 Ada.Directories.Copy_File behavior tmoran 2011-02-19 23:01 ` Vinzent Hoefler 2011-02-20 0:01 ` tmoran 2011-02-20 0:31 ` Vinzent Hoefler 2011-02-20 11:01 ` Martin 2011-02-20 20:19 ` tmoran 2011-02-20 20:25 ` Vinzent Hoefler 2011-02-21 18:05 ` Adam Beneschan 2011-02-21 19:26 ` Vinzent Hoefler 2011-02-21 19:41 ` Adam Beneschan 2011-02-21 20:42 ` Vinzent Hoefler 2011-02-26 2:41 ` Randy Brukardt 2011-02-26 3:22 ` Adam Beneschan 2011-03-01 3:17 ` Randy Brukardt 2011-02-26 2:34 ` Randy Brukardt
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox