Sebb wrote:
On 03/10/05, John E. Malmberg <[EMAIL PROTECTED]> wrote:
Sebb wrote:
On 03/10/05, John E. Malmberg <[EMAIL PROTECTED]> wrote:
New files opened for write are created in the first directory of a
search list. New files opened for append are created in the last
directory of a search list.
Are you sure appended files use the last directory?
This doesn't happen with Perl 5.5-3A3.
I am going by the behavior of the file system.
When using C on VMS 7.3-2 on an ODS-2 volume the following code:
#include stdio
main(){
FILE *out=fopen("chain:c.tmp","a");
if (out == NULL) perror("fopen");
fprintf(out,"test\n");
fclose(out);
}
creates the output file in the first link in the chain, not the last.
But if c.tmp already exists elsewhere in the chain, it is appended to correctly.
And that is going through the CRTL. Until your example, I was not aware
that it was behaving differently than what the file system does when you
make the same request with one call instead of several.
The implication here is that the CRTL looked for the file in one
operation and when it did not find it, did a create as as separate
operation.
If you try the same experiment from DCL you will get a different result.
And it is quite possible that if you use the RMS extensions to the
UNIXIO, Standard IO open/creat calls to convert an open for write to do
a "create if non-existent", it may behave differently than fopen().
Personally I think that having append go to the end of the search list
to create a new file is an undesired and unexpected feature, but that is
the way it works.
It appears that possibly when fopen() was implemented, that either
someone deliberately decided to make sure the file was always created at
the beginning of a search list, or it could have been an artifact of how
it was implemented. That was so long ago, it might take a while to find
out for sure. In any case it appears that the the CRTL documentation
needs an update.
Like Perl, the CRTL is in many ways trying to be more compatible with
UNIX behavior than it is with expected VMS behavior. Unfortunately
sometimes as a result it ended up with neither the expected VMS behavior
or X/Open defined UNIX behavior, and by the time that is discovered, VMS
specific programs were written that depended on the existing behavior.
Such things get fixed/changed based on customer impact. And in some
cases all that is really needed is to document the behavior.
-John
[EMAIL PROTECTED]
Personal Opinion Only
