landay@cory.Berkeley.EDU (James A. Landay) (07/17/88)
Last night (at 3AM) I accidently copied a file over itself.
This seems to trash the file rather than touching the date
or doing nothing. Will this be fixed in the new ROM version? (Atari?)
thanks,
James A. Landay
ARPA: landay@cory.berkeley.edu
ucbvax!cory!landayleo@philmds.UUCP (Leo de Wit) (07/19/88)
In article <4507@pasteur.Berkeley.Edu> landay@cory.Berkeley.EDU (James A. Landay) writes: >Last night (at 3AM) I accidently copied a file over itself. >This seems to trash the file rather than touching the date >or doing nothing. Will this be fixed in the new ROM version? (Atari?) Tried it with a 14K file (i.e. copying from the Desktop), but the contents remained the same. The date was changed. Then I tried it with a simple copy program, like this: #include <stdio.h> #include <fcntl.h> #include <osbind.h> main() { int fdi, fdo, nread; char buf[BUFSIZ]; fdi = Fopen("test.dat",O_RDONLY); fdo = Fopen("test.dat",O_WRONLY|O_CREAT|O_TRUNC); while ((nread = Fread(fdi,BUFSIZ,buf)) > 0) { Fwrite(fdo,nread,buf); } Fclose(fdi); Fclose(fdo); } Odd enough, even though O_TRUNC was specified the contents remained the same (in Unix you would get an empty file). Also the date was not changed. Interchanging the Fopen calls didn't make any difference. So the next question is perhaps: what ROM version are you using now? Leo. B.T.W. What in the world made the GEMDOS writers decide to swap the second and third parameter in the Fread and Fwrite calls, compared with Unix read() and write() ? Since they 'leant' quite a few things from Unix, wouldn't it have been easier to use the same parameter ordering?
gert@nikhefh.hep.nl (Gert Poletiek) (07/20/88)
In article <565@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <4507@pasteur.Berkeley.Edu> landay@cory.Berkeley.EDU (James A. Landay) writes: >>Last night (at 3AM) I accidently copied a file over itself. >>This seems to trash the file rather than touching the date >>or doing nothing. Will this be fixed in the new ROM version? (Atari?) > >Tried it with a 14K file (i.e. copying from the Desktop), but the >contents remained the same. The date was changed. >Then I tried it with a simple copy program, like this: > >#include <stdio.h> >#include <fcntl.h> >#include <osbind.h> > >main() >{ > int fdi, fdo, nread; > char buf[BUFSIZ]; > > fdi = Fopen("test.dat",O_RDONLY); > fdo = Fopen("test.dat",O_WRONLY|O_CREAT|O_TRUNC); > > while ((nread = Fread(fdi,BUFSIZ,buf)) > 0) { > Fwrite(fdo,nread,buf); > } > Fclose(fdi); > Fclose(fdo); >} > >Odd enough, even though O_TRUNC was specified the contents remained the >same (in Unix you would get an empty file). Also the date was not changed. >Interchanging the Fopen calls didn't make any difference. >So the next question is perhaps: what ROM version are you using now? > > Leo. > >B.T.W. What in the world made the GEMDOS writers decide to swap the >second and third parameter in the Fread and Fwrite calls, compared with >Unix read() and write() ? Since they 'leant' quite a few things from Unix, >wouldn't it have been easier to use the same parameter ordering? The GemDos Fopen call has no flag O_TRUNC. Sometimes GemDos is way off the Unix standard. (certainly in speed). In order to mimic the O_TRUNC you should have your own open call, something like this: open ( name, mode ) char *name; int mode; { int fd; struct statbuf statbuf; if ( mode & O_TRUNC ) { if ( stat ( name, &statbuf ) == 0 ) { if ( statbuf.attr & (F_VOLUME|F_DIR|F_READONLY) ) { errno = EACCDN; return ( OPENERR ); } if ( unlink ( name ) < 0 ) return ( OPENERR ); mode |= O_CREAT; } } fd = Fopen ( name, mode & 3 ); if ( fd < -3 && ( mode & O_CREAT ) ) /* try to create the file */ fd = Fcreate ( name, 0 ); if ( fd >= 0 && ( mode & O_APPEND ) ) /* seek to EOF */ Fseek ( 0L, fd, 2 ); if ( fd < -3 ) { errno = fd; return ( OPENERR ); } return ( fd ); } Also notice the nice effect of writing to a 1024 byte long file with read and write access on byte 24 for example. The file will remain 1024 bytes long! Gert Poletiek NIKHEF-H, Dutch National Institute for Nuclear and High Energy Physics Kruislaan 409, P.O.Box 41882, 1009 DB Amsterdam, The Netherlands UUCP: {decvax,cernvax,unido,seismo}!mcvax!nikhefh!gert bitnet: nikhefh!gert@mcvax.bitnet, U00025@hasara5.bitnet
landay@cory.Berkeley.EDU (James A. Landay) (07/20/88)
In article <565@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: >In article <4507@pasteur.Berkeley.Edu> landay@cory.Berkeley.EDU (James A. Landay) writes: >>Last night (at 3AM) I accidently copied a file over itself. >>This seems to trash the file rather than touching the date >>or doing nothing. Will this be fixed in the new ROM version? (Atari?) > >Tried it with a 14K file (i.e. copying from the Desktop), but the >contents remained the same. The date was changed. > [stuff deleted ] >So the next question is perhaps: what ROM version are you using now? > > Leo. > I am using the US TOS ROM that is the one available prior to the Megas (it is probably 1.5 years old) I just tried it again. I first booted with a disk that had no auto folder or desk accessories. I then copied the file (an 18K text file, a 1K file seemed to work fine) to the same directory. Got the message file already exists give new copy name (or whatever it says.) Left it the same. Copied the file. Looked at it. It is a repeat of the first 20 lines or so, over and over. What the hell is this? Does anyone have a program that will return my ROM identification so that we know which ROMs have it? By the way, why does deleteting files take so long compared to MeSsyDOS. THANKS, hanks James James A. Landay ARPA: landay@cory.berkeley.edu ucbvax!cory!landay
FORSTER@cs.umass.EDU (David Forster) (07/21/88)
pasteur!cory.Berkeley.EDU!landay@ucbvax.Berkeley.EDU (James A. Landay) writes: >... >I am using the US TOS ROM that is the one available prior to the Megas >(it is probably 1.5 years old) So am I. > >I just tried it again. I first booted with a disk that had no auto >folder or desk accessories. I then copied the file (an 18K text file, a >1K file seemed to work fine) to the same directory. Got the message >file already exists give new copy name (or whatever it says.) Left it the >same. Copied the file. Looked at it. It is a repeat of the first 20 >lines or so, over and over. > I have had similar problems, but the files are created by uEmacs 3.8f on a RAMdisk. I've wondered before how the files got to be that way. Maybe someone out there can give us information on how the file ``system'' is built? (I know, the system isn't that bad, but I've worked with better and faster ones.) - David Forster ARPA/MILnet: forster@cs.umass.edu BITnet: forster@umass