 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : When it crashes does it close files?
| Author | Message | ||||
| Paul_L Guru  Joined: 03/03/2016 Location: United StatesPosts: 769 |
For debugging purposes running under both DOS and on a PIC chip will MMBasic close and flush a debug file as it crashes? open "stuff.txt" for output as #1 print #1, "line 1" ' something in here screws up and it crashes print #1, "line 2" close #1 It's obvious that "line 2" will never be printed, but will the first print line "line 1" appear and will the file be closed? If it crashes back to a the MMBasic interperter command window will I be able to enter "CLOSE #1" in immediate mode to close the file? Will the file then be readable? Paul in NY |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
Only one way to see;  The data probably gets written to file progressively but without closing, not good. For the best security, close then reopen frequently. Even reopening an existing file to append might be risky. Jim VK7JH MMedit |
||||
| TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6283 |
More playing I added a bit more code And ran it. Not only was the two lines from this run there but also the first line from the previous program. I assume that there is a lonely "line 1" sitting there in nowhere land from the error in the second run through the printing. There might be a timed flush at play somewhere. And if you go back and enter CLOSE #1 at the command prompt, the extra bytes get written. This is even after opening the file with XMODEM in between crashing and closing. All my testing was with a MMX running V5.4 VK7JH MMedit |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
The file system code used by the Micromite is FatFs. This has a 512 byte buffer per open file. Writes take place to the buffer and are flushed to disk when the buffer is full or when the file is closed. To be certain each write takes place close the file after each write and re-open it with append access. There is a FatFs command to force a buffer flush and Geoff and I discussed including a Basic command to execute it but, from what I can remember, we decided using close/re-open was good enough to avoid using another valuable command slot. |
||||
| matherp Guru Joined: 11/12/2012 Location: United KingdomPosts: 10310 |
The file system code used by the Micromite is FatFs. DOS uses standard Microsoft file I/O and may well behave differently. FatFs has a 512 byte buffer per open file. Writes take place to the buffer and are flushed to disk when the buffer is full or when the file is closed. To be certain each write takes place close the file after each write and re-open it with append access. There is a FatFs command to force a buffer flush and Geoff and I discussed including a Basic command to execute it but, from what I can remember, we decided using close/re-open was good enough to avoid using another valuable command slot. |
||||
| Phil23 Guru Joined: 27/03/2016 Location: AustraliaPosts: 1667 |
So essentially, If the buffer contains the less than 512 bytes, not yet written, and everything crashes, the Directory entry & FAT entries will still be intact as per the last flush to disk. Therefore the file should be intact & readable, just missing the last < 512 bytes waiting to be written from the buffer. Is that a correct interpretation? Phil. |
||||
| greybeard Senior Member  Joined: 04/01/2010 Location: AustraliaPosts: 174 |
Working back from a definition of a program 'crashing', how could it guarantee to close a file? The program has failed and is operating in an unknown mode. If it's possible (haven't looked) to write error routines to take control if a program doesn't work as expected then it may be possible to get that to close all open files. (This is how the 'big boys' try to cope with potential operation failures) |
||||
| Paul_L Guru Joined: 03/03/2016 Location: United StatesPosts: 769 |
Yep greybeard, I'm trying to figure out how to cope with potential operation failures. In the process of playing with the new DOS interpreter I found that the "#" symbol in "print #n, s$" is apparently not optional as stated in the manual .... "In the following commands/functions the # in #fnbr is optional and may be omitted." Run this code under DOS and then take a look at the files generated. T3.txt and t5.txt come up empty when I run it. s$="writing t1.txt" open "t1.txt" for output as 1 print s$ print #1, s$ close 1 f$="t2.txt" b%=1 s$="writing t2.txt" open f$ for output as b% ? s$ ? #b%, s$ ' WITH THE "#" close b% f$="t3.txt" b%=1 s$="writing t3.txt" open f$ for output as b% ? s$ ? b%, s$ ' WITHOUT THE "#" close b% f$="t4.txt" b%=1 s$="writing "+f$+" as #"+str$(b%) if openout%(f$,b%) then ? s$ p1(b%,s$) close b% endif f$="t5.txt" b%=1 s$="writing "+f$+" as #"+str$(b%) if openout%(f$,b%) then ? s$ p2(b%,s$) close b% endif ? "DONE" end function openout%(fn$,fb%) OPTION ERROR CONTINUE open fn$ for output as fb% if MM.ERRNO = 0 then print "Opened "+fn$+" for output as #"+str$(fb%)+"." openout%=1 else print "UBLEWIT! Can't open "+fn$+" for output." openout%=0 endif OPTION ERROR ABORT END FUNCTION 'openout%(fn$,bf%) SUB p1(fb%,s$) print s$ print #fb%, s$ ' WITH THE "#" END SUB 'pt(bf%,s$) SUB p2(fb%,s$) print s$ print fb%, s$ ' WITHOUT THE "#" END SUB 'pt(bf%,s$) Also something more peculiar ..... The new DOS interpreter behaves differently than the old one. The new one insists that I type <run "t.bas"><ENTER> (including the quotes) to start a file. The old one would willingly run the file by typing <t.bas><ENTER> or even <t><ENTER>. I'm not sure, but the old one may have required <t.bas><ENTER> the first time and then only <t><ENTER> the second time. It seemed to remember what files were out there. Hmmmmmmm... Paul in NY |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
