Ada.Directories.Copy_File behavior

Ada.Directories.Copy_File behavior

[tmoran]

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.

Re: Ada.Directories.Copy_File behavior

[Vinzent Hoefler]

  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"

Re: Ada.Directories.Copy_File behavior

[tmoran]

> 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.

Re: Ada.Directories.Copy_File behavior

[Vinzent Hoefler]

  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.

Re: Ada.Directories.Copy_File behavior

[Martin]

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

Re: Ada.Directories.Copy_File behavior

[tmoran]

> > 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

Re: Ada.Directories.Copy_File behavior

[Vinzent Hoefler]

  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"

Re: Ada.Directories.Copy_File behavior

[Adam Beneschan]

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

Re: Ada.Directories.Copy_File behavior

[Vinzent Hoefler]

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"

Re: Ada.Directories.Copy_File behavior

[Adam Beneschan]

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

Re: Ada.Directories.Copy_File behavior

[Vinzent Hoefler]

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"

Re: Ada.Directories.Copy_File behavior

[Randy Brukardt]

"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.

Re: Ada.Directories.Copy_File behavior

[Adam Beneschan]

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

Re: Ada.Directories.Copy_File behavior

[Randy Brukardt]

"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.

Re: Ada.Directories.Copy_File behavior

[Randy Brukardt]

<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.