sgr@ednor.UUCP (Steve Reppucci) (05/04/89)
Here's a question concerning the DOS APPEND command.
I'm trying to open a file from a C program (using either open() or
fopen()... they behave similarly). I'm running DOS 3.3, and compiling
with MSC-51 (although I get the same results if I compile with TC-20).
I have set a 'data search path' using the APPEND command. It seems
that if the file I'm attempting to open doesn't exist, AND a file
with the same name exists in a directory that's in the search path,
then that file (in the search path) gets opened (and overwritten).
Note that this happens even though I've specified the full DOS pathname
in the open call.
My question is, is this correct behavior ?? Seems unlikely to me that
the APPEND search path should be accessed at all if the file is opened
using a full pathspec. And is this a compiler problem, or a DOS problem ?
Is there a workaround ??
Please reply via E-Mail, I'll post a summary if there's any interest.
Thanks in advance for any responses.
A simplified test case output follows:
=======================================================
E:\TEST1> DIR
Directory of E:\TEST1
. <DIR> 5-03-89 12:58p
.. <DIR> 5-03-89 12:58p
TEST C 375 5-03-89 1:07p
TEST EXE 9502 5-03-89 1:08p
FOO TMP 37 5-03-89 1:25p
5 File(s) 764416 bytes free
E:\TEST1> type foo.tmp
This is data from \test1\foo.tmp
E:\TEST1> dir \test2
Directory of E:\TEST2
. <DIR> 5-03-89 12:58p
.. <DIR> 5-03-89 12:58p
2 File(s) 763904 bytes free
E:\TEST1> type test.c
/* #include <needed_headers> */
main() { /* Built with MSC 5.1 */
int f;
static char s[] = "This data was written to \\test2\\foo.tmp";
if ((f = open( "\\TEST2\\FOO.TMP", O_BINARY | O_RDWR)) == (-1)) {
puts("\nError opening file\07");
exit(0);
}
write( f, s, strlen(s));
close(f); exit(0);
}
E:\TEST1> append e:\test1
E:\TEST1> append
APPEND=E:\TEST1
E:\TEST1> dir
Directory of E:\TEST1
. <DIR> 5-03-89 12:58p
.. <DIR> 5-03-89 12:58p
TEST C 375 5-03-89 1:07p
TEST EXE 9502 5-03-89 1:08p
FOO TMP 39 5-03-89 1:25p
5 File(s) 763392 bytes free
E:\TEST1> test
E:\TEST1> type foo.tmp
This data was written to \test2\foo.tmp
E:\TEST1> dir
Directory of E:\TEST2
. <DIR> 5-03-89 12:58p
.. <DIR> 5-03-89 12:58p
2 File(s) 762880 bytes free
--
Steve Reppucci Boston Business Computing, Ltd.
uunet!ednor!sgrleonard@bucket.UUCP (Leonard Erickson) (05/06/89)
In article <762@ednor.UUCP> sgr@ednor.UUCP (Steve Reppucci) writes:
<
<Here's a question concerning the DOS APPEND command.
<
<I'm trying to open a file from a C program (using either open() or
<fopen()... they behave similarly). I'm running DOS 3.3, and compiling
<with MSC-51 (although I get the same results if I compile with TC-20).
<I have set a 'data search path' using the APPEND command. It seems
<that if the file I'm attempting to open doesn't exist, AND a file
<with the same name exists in a directory that's in the search path,
<then that file (in the search path) gets opened (and overwritten).
<Note that this happens even though I've specified the full DOS pathname
<in the open call.
<
<My question is, is this correct behavior ?? Seems unlikely to me that
<the APPEND search path should be accessed at all if the file is opened
<using a full pathspec. And is this a compiler problem, or a DOS problem ?
<Is there a workaround ??
This "normal" behavior for APPEND. The problem is that APPEND is an
*external* DOS command rather than an internal one. I'm not sure how
APPEND works, but I suspect it ties into the "file not found" error or
some such.
APPEND is kludged onto DOS rather than integrated into it. It takes
over if DOS returns "file not found". So if you are using it, it *will*
return a file in another directory on the search path if no file is
found in the current directory. DOS doesn't even know that the file is
in another directory!
Try this:
create a file in a directory on the APPEND path
go to a different directory
do a dir using wildcards that would find the file
If no files in the current dir match, dir will cheerfully list the
file *as if it was in the current directory*! In other words, APPEND
works by *lying* to DOS! My advice (and that of everyone who is aware
of APPEND's "odd" behavior is not to use it! It is more dangerous than
helpful. Especially since not all DOS functions use it. (I think that
only the find first and find next functions tie into it...) This way
lies massively inconsistent behavior. Such as opening a file with
a wordprocessor, editing it, and then having the wp crash on exit
because when it tries to rename the original file, the DOS rename call
can't find it! Blecch!
--
Leonard Erickson ...!tektronix!reed!percival!bucket!leonard
CIS: [70465,203]
"I'm all in favor of keeping dangerous weapons out of the hands of fools.
Let's start with typewriters." -- Solomon Shortsimon@ms.uky.edu (G. Simon Gales) (05/12/89)
In article <762@ednor.UUCP> sgr@ednor.UUCP (Steve Reppucci) writes: > >Here's a question concerning the DOS APPEND command. > >[ Description of APPEND problem omitted ] I have noticed another problem with DOS APPEND, in ver 4.00/4.01 When APPEND is installed, and I do a 'dir a:', I get the root directory of the current disk (harddisk). I cannot read the directory on the floppy without making it my current drive first. The directory listing that is produced DOES state the correct drive/path, but it is not the one I specified. Has anyone else noticed this? Append seems really screwy sometimes... -- /------------------------------------------------------------------------\ Simon Gales@University of Ky {rutgers, uunet}!ukma!simon - simon@ms.uky.edu - simon@UKMA.BITNET
gahooten@ames.arc.nasa.gov (Greg A. Hooten) (05/13/89)
In article <11686@s.ms.uky.edu> simon@ms.uky.edu (G. Simon Gales) writes: >When APPEND is installed, and I do a 'dir a:', I get the root directory >of the current disk (harddisk). I cannot read the directory on the >floppy without making it my current drive first. (Stuff deleted...) >Has anyone else noticed this? Append seems really screwy sometimes... > > Simon Gales@University of Ky The DOS Append command in DOS 3.3 did the same thing. In DOS 3.3, if the drive that you attempt to read had no data in it, then the append command takes over. The first appended path is searched, and if it has files, then those are displayed. IF there is nothing in that appended directory, then the next in the path. This actually makes sence since the append command tries to satisfy whatever command you give it by searching first the current drive, then any appended drive (as long as the command append /x /e is in the Autoexec.bat file. You can eliminate that append command by typing APPEND; This will stop the append from being used. GAH!