What is the danger involved in trying to write already closed file with Commodore 1541 disk drive?











up vote
16
down vote

favorite
1












The Commodore 1541 disk drive and other IEC devices are self-contained computers. The operating system runs on the drive itself. This setup significantly improves the flexibility. As a side effect, if there is an error during a disk operation, the computer doesn't know about it. Only the drive knows. You had to open the error channel and listen for error codes to check errors.



When you open the error channel and multiple files at the same time, all open files are closed when you close the error channel. Thanks to this fail-proof mechanism, if you encounter a disk error while working with several files, you can close the error channel and safely quit the program without knowing which files are open. You don't have to keep track of open files, since they all will be closed automatically.



However, the 1541 user manual says that automatically closing files in this way is dangerous because BASIC doesn't know they were closed and this is a very dangerous situation!



What is the danger involved in trying to write a file that's already closed? The only risk I see is getting a write error.



I've copied the warning from the 1541 users manual below:




If you close the error channel while other files are OPEN, the disk
drive will CLOSE them for you, but BASIC will still think they are
open (unless you CLOSE them properly), and let you to try to write to
them.



NOTE: If your BASIC program leads you into an error condition, all
files are CLOSED in BASIC, without CLOSEing them on your disk drive!
This is a very dangerous condition. You should immediately type the
statement CLOSE 12: OPEN 15, 8, 15: CLOSE 15. This will re-initialize
your drive and make all your files safe.











share|improve this question




















  • 2




    A pdf of the manual: commodore.ca/manuals/pdfs/… The text in the question is on top of page 19.
    – UncleBod
    Nov 26 at 14:30

















up vote
16
down vote

favorite
1












The Commodore 1541 disk drive and other IEC devices are self-contained computers. The operating system runs on the drive itself. This setup significantly improves the flexibility. As a side effect, if there is an error during a disk operation, the computer doesn't know about it. Only the drive knows. You had to open the error channel and listen for error codes to check errors.



When you open the error channel and multiple files at the same time, all open files are closed when you close the error channel. Thanks to this fail-proof mechanism, if you encounter a disk error while working with several files, you can close the error channel and safely quit the program without knowing which files are open. You don't have to keep track of open files, since they all will be closed automatically.



However, the 1541 user manual says that automatically closing files in this way is dangerous because BASIC doesn't know they were closed and this is a very dangerous situation!



What is the danger involved in trying to write a file that's already closed? The only risk I see is getting a write error.



I've copied the warning from the 1541 users manual below:




If you close the error channel while other files are OPEN, the disk
drive will CLOSE them for you, but BASIC will still think they are
open (unless you CLOSE them properly), and let you to try to write to
them.



NOTE: If your BASIC program leads you into an error condition, all
files are CLOSED in BASIC, without CLOSEing them on your disk drive!
This is a very dangerous condition. You should immediately type the
statement CLOSE 12: OPEN 15, 8, 15: CLOSE 15. This will re-initialize
your drive and make all your files safe.











share|improve this question




















  • 2




    A pdf of the manual: commodore.ca/manuals/pdfs/… The text in the question is on top of page 19.
    – UncleBod
    Nov 26 at 14:30















up vote
16
down vote

favorite
1









up vote
16
down vote

favorite
1






1





The Commodore 1541 disk drive and other IEC devices are self-contained computers. The operating system runs on the drive itself. This setup significantly improves the flexibility. As a side effect, if there is an error during a disk operation, the computer doesn't know about it. Only the drive knows. You had to open the error channel and listen for error codes to check errors.



When you open the error channel and multiple files at the same time, all open files are closed when you close the error channel. Thanks to this fail-proof mechanism, if you encounter a disk error while working with several files, you can close the error channel and safely quit the program without knowing which files are open. You don't have to keep track of open files, since they all will be closed automatically.



However, the 1541 user manual says that automatically closing files in this way is dangerous because BASIC doesn't know they were closed and this is a very dangerous situation!



What is the danger involved in trying to write a file that's already closed? The only risk I see is getting a write error.



I've copied the warning from the 1541 users manual below:




If you close the error channel while other files are OPEN, the disk
drive will CLOSE them for you, but BASIC will still think they are
open (unless you CLOSE them properly), and let you to try to write to
them.



NOTE: If your BASIC program leads you into an error condition, all
files are CLOSED in BASIC, without CLOSEing them on your disk drive!
This is a very dangerous condition. You should immediately type the
statement CLOSE 12: OPEN 15, 8, 15: CLOSE 15. This will re-initialize
your drive and make all your files safe.











share|improve this question















The Commodore 1541 disk drive and other IEC devices are self-contained computers. The operating system runs on the drive itself. This setup significantly improves the flexibility. As a side effect, if there is an error during a disk operation, the computer doesn't know about it. Only the drive knows. You had to open the error channel and listen for error codes to check errors.



When you open the error channel and multiple files at the same time, all open files are closed when you close the error channel. Thanks to this fail-proof mechanism, if you encounter a disk error while working with several files, you can close the error channel and safely quit the program without knowing which files are open. You don't have to keep track of open files, since they all will be closed automatically.



However, the 1541 user manual says that automatically closing files in this way is dangerous because BASIC doesn't know they were closed and this is a very dangerous situation!



What is the danger involved in trying to write a file that's already closed? The only risk I see is getting a write error.



I've copied the warning from the 1541 users manual below:




If you close the error channel while other files are OPEN, the disk
drive will CLOSE them for you, but BASIC will still think they are
open (unless you CLOSE them properly), and let you to try to write to
them.



NOTE: If your BASIC program leads you into an error condition, all
files are CLOSED in BASIC, without CLOSEing them on your disk drive!
This is a very dangerous condition. You should immediately type the
statement CLOSE 12: OPEN 15, 8, 15: CLOSE 15. This will re-initialize
your drive and make all your files safe.








disk-drive cbm






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Nov 26 at 9:59









Wilson

10.3k546122




10.3k546122










asked Nov 26 at 9:46









wizofwor

1,2751529




1,2751529








  • 2




    A pdf of the manual: commodore.ca/manuals/pdfs/… The text in the question is on top of page 19.
    – UncleBod
    Nov 26 at 14:30
















  • 2




    A pdf of the manual: commodore.ca/manuals/pdfs/… The text in the question is on top of page 19.
    – UncleBod
    Nov 26 at 14:30










2




2




A pdf of the manual: commodore.ca/manuals/pdfs/… The text in the question is on top of page 19.
– UncleBod
Nov 26 at 14:30






A pdf of the manual: commodore.ca/manuals/pdfs/… The text in the question is on top of page 19.
– UncleBod
Nov 26 at 14:30












2 Answers
2






active

oldest

votes

















up vote
19
down vote













Just based on the reading, I think you may be misunderstanding the sense of the warning.



You appear to think that the problem is with the disk system closing the files (because you have closed the error channel) and BASIC not knowing about it. I suspect in that case you probably would just get an error if you later tried to access them(a).



However, the "danger" bit looks like it's the other sense, with BASIC erroring out (closing its files) but without having closed the files on the disk system. If you re-read the warning (my bold), that may be clearer:




NOTE: If your BASIC program leads you into an error condition, all files are CLOSED in BASIC, without CLOSEing them on your disk drive!




This, I'd hazard to guess, may be dangerous because the disk still has them open and it's unclear what would happen then if they were reopened by BASIC, or if they were cached and you powered down, or if the administrative information on the disk weren't updated, or possibly half a dozen other suspect scenarios I could come up with if I had the time and inclination :-)



That's why it's suggesting you execute that (rather arcane) sequence of commands, to safely re-initiliase the disk system and put it in a known state. And, before you go trying this, you should be aware that there's no file # 12 involved anywhere. The reset command is:



CLOSE 15: OPEN 15, 8, 15: CLOSE 15




(a) Though I can't be sure, having never had the opportunity to even own a C64 - my babies were ZX80, TRS-80, Apple ][ and the very-little-known COMX-35. However, I'm considered reasonably good at decoding documentation, hence my answer.






share|improve this answer



















  • 2




    That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
    – TripeHound
    Nov 26 at 14:50






  • 1




    That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
    – Tommy
    Nov 26 at 15:35








  • 1




    @Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
    – BlackJack
    Nov 27 at 12:29










  • @BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
    – Tommy
    Nov 27 at 14:34










  • @Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
    – BlackJack
    Nov 27 at 14:39


















up vote
7
down vote













In what might be borderline as acceptably a separate answer from paxdiablo, cf. the 1541 ROM disassembly. It's fully commented, so the following comments are a companion's guide to draw your attention to what I think are the relevant bits, see the full thing for a more thorough treatment.



The main dispatch loop, which listens to the serial bus and acts upon incoming commands, starts at E85B. Notice at E8CE that it'll segue to DAC0 if a CLOSE is received.



That code treats 15 as a special case — if that's received it'll just count down from 14 to 0 calling close file on each; that's the loop that is seeded at DAEC and then consists of DAF0, DAF3 and DAF5. For any regular channel it jumps straight to the close file routine.



The close individual file routine is at DB02 but an immediate corollary:




  • the ROM itself treats a request to close all as a simple sequence of CLOSE 14, CLOSE 13 ... CLOSE 0. The outer loop doesn't check whether the files are open, and it ends up at exactly the same place as if you'd typed CLOSE X. Therefore one can assume a priori that it is safe to close files that aren't open.


One doesn't really need to assume though; check out the test from DB04: is there actually anything associated with this channel? If not, stop harmlessly.



Re:




all files are CLOSED in BASIC, without CLOSEing them on your disk drive! This is a very dangerous condition.




and the implication that CLOSEing does something meaningful on the disk drive, skip ahead to DB20. From there there's a sequence of:




  • write last block;

  • write entry in directory and block;

  • write BAM (the table of which blocks on the disk are unoccupied);

  • close channel and exit this routine.


Followed by a separate:




  • get buffer number;

  • write block.


The various selection parts between DB04 and DB20 just make a selection about which of those they start with. But all paths go through at least one 'write'; specifically:




  • the last block and directory are skipped if you're involved in direct access, i.e. not performing file operations; and

  • the get buffer number/write block path is taken, ignoring the directory and BAM, if you're dealing with a REL file, which are specially allocated to be contiguous so there's no further global bookkeeping once the thing exists.


So for non-REL files, failure to close may lead to the data at the end potentially being missing, and the directory and BAM not being updated.



For REL files, failure to close may lead to the particular section of the file you were working on not being updated.



Re: attempting to write to a file that isn't open, start at CFF1; that jumps to C1C8 if no such file is open, which does as you expect by heading off to E645 harmlessly to report an error.






share|improve this answer



















  • 2




    Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
    – Tommy
    Nov 27 at 20:15








  • 2




    Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
    – paxdiablo
    Nov 27 at 21:32











Your Answer








StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "648"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);

StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});

function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
noCode: true, onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});


}
});














draft saved

draft discarded


















StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8384%2fwhat-is-the-danger-involved-in-trying-to-write-already-closed-file-with-commodor%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown

























2 Answers
2






active

oldest

votes








2 Answers
2






active

oldest

votes









active

oldest

votes






active

oldest

votes








up vote
19
down vote













Just based on the reading, I think you may be misunderstanding the sense of the warning.



You appear to think that the problem is with the disk system closing the files (because you have closed the error channel) and BASIC not knowing about it. I suspect in that case you probably would just get an error if you later tried to access them(a).



However, the "danger" bit looks like it's the other sense, with BASIC erroring out (closing its files) but without having closed the files on the disk system. If you re-read the warning (my bold), that may be clearer:




NOTE: If your BASIC program leads you into an error condition, all files are CLOSED in BASIC, without CLOSEing them on your disk drive!




This, I'd hazard to guess, may be dangerous because the disk still has them open and it's unclear what would happen then if they were reopened by BASIC, or if they were cached and you powered down, or if the administrative information on the disk weren't updated, or possibly half a dozen other suspect scenarios I could come up with if I had the time and inclination :-)



That's why it's suggesting you execute that (rather arcane) sequence of commands, to safely re-initiliase the disk system and put it in a known state. And, before you go trying this, you should be aware that there's no file # 12 involved anywhere. The reset command is:



CLOSE 15: OPEN 15, 8, 15: CLOSE 15




(a) Though I can't be sure, having never had the opportunity to even own a C64 - my babies were ZX80, TRS-80, Apple ][ and the very-little-known COMX-35. However, I'm considered reasonably good at decoding documentation, hence my answer.






share|improve this answer



















  • 2




    That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
    – TripeHound
    Nov 26 at 14:50






  • 1




    That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
    – Tommy
    Nov 26 at 15:35








  • 1




    @Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
    – BlackJack
    Nov 27 at 12:29










  • @BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
    – Tommy
    Nov 27 at 14:34










  • @Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
    – BlackJack
    Nov 27 at 14:39















up vote
19
down vote













Just based on the reading, I think you may be misunderstanding the sense of the warning.



You appear to think that the problem is with the disk system closing the files (because you have closed the error channel) and BASIC not knowing about it. I suspect in that case you probably would just get an error if you later tried to access them(a).



However, the "danger" bit looks like it's the other sense, with BASIC erroring out (closing its files) but without having closed the files on the disk system. If you re-read the warning (my bold), that may be clearer:




NOTE: If your BASIC program leads you into an error condition, all files are CLOSED in BASIC, without CLOSEing them on your disk drive!




This, I'd hazard to guess, may be dangerous because the disk still has them open and it's unclear what would happen then if they were reopened by BASIC, or if they were cached and you powered down, or if the administrative information on the disk weren't updated, or possibly half a dozen other suspect scenarios I could come up with if I had the time and inclination :-)



That's why it's suggesting you execute that (rather arcane) sequence of commands, to safely re-initiliase the disk system and put it in a known state. And, before you go trying this, you should be aware that there's no file # 12 involved anywhere. The reset command is:



CLOSE 15: OPEN 15, 8, 15: CLOSE 15




(a) Though I can't be sure, having never had the opportunity to even own a C64 - my babies were ZX80, TRS-80, Apple ][ and the very-little-known COMX-35. However, I'm considered reasonably good at decoding documentation, hence my answer.






share|improve this answer



















  • 2




    That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
    – TripeHound
    Nov 26 at 14:50






  • 1




    That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
    – Tommy
    Nov 26 at 15:35








  • 1




    @Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
    – BlackJack
    Nov 27 at 12:29










  • @BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
    – Tommy
    Nov 27 at 14:34










  • @Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
    – BlackJack
    Nov 27 at 14:39













up vote
19
down vote










up vote
19
down vote









Just based on the reading, I think you may be misunderstanding the sense of the warning.



You appear to think that the problem is with the disk system closing the files (because you have closed the error channel) and BASIC not knowing about it. I suspect in that case you probably would just get an error if you later tried to access them(a).



However, the "danger" bit looks like it's the other sense, with BASIC erroring out (closing its files) but without having closed the files on the disk system. If you re-read the warning (my bold), that may be clearer:




NOTE: If your BASIC program leads you into an error condition, all files are CLOSED in BASIC, without CLOSEing them on your disk drive!




This, I'd hazard to guess, may be dangerous because the disk still has them open and it's unclear what would happen then if they were reopened by BASIC, or if they were cached and you powered down, or if the administrative information on the disk weren't updated, or possibly half a dozen other suspect scenarios I could come up with if I had the time and inclination :-)



That's why it's suggesting you execute that (rather arcane) sequence of commands, to safely re-initiliase the disk system and put it in a known state. And, before you go trying this, you should be aware that there's no file # 12 involved anywhere. The reset command is:



CLOSE 15: OPEN 15, 8, 15: CLOSE 15




(a) Though I can't be sure, having never had the opportunity to even own a C64 - my babies were ZX80, TRS-80, Apple ][ and the very-little-known COMX-35. However, I'm considered reasonably good at decoding documentation, hence my answer.






share|improve this answer














Just based on the reading, I think you may be misunderstanding the sense of the warning.



You appear to think that the problem is with the disk system closing the files (because you have closed the error channel) and BASIC not knowing about it. I suspect in that case you probably would just get an error if you later tried to access them(a).



However, the "danger" bit looks like it's the other sense, with BASIC erroring out (closing its files) but without having closed the files on the disk system. If you re-read the warning (my bold), that may be clearer:




NOTE: If your BASIC program leads you into an error condition, all files are CLOSED in BASIC, without CLOSEing them on your disk drive!




This, I'd hazard to guess, may be dangerous because the disk still has them open and it's unclear what would happen then if they were reopened by BASIC, or if they were cached and you powered down, or if the administrative information on the disk weren't updated, or possibly half a dozen other suspect scenarios I could come up with if I had the time and inclination :-)



That's why it's suggesting you execute that (rather arcane) sequence of commands, to safely re-initiliase the disk system and put it in a known state. And, before you go trying this, you should be aware that there's no file # 12 involved anywhere. The reset command is:



CLOSE 15: OPEN 15, 8, 15: CLOSE 15




(a) Though I can't be sure, having never had the opportunity to even own a C64 - my babies were ZX80, TRS-80, Apple ][ and the very-little-known COMX-35. However, I'm considered reasonably good at decoding documentation, hence my answer.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 27 at 0:44

























answered Nov 26 at 11:29









paxdiablo

1,6051235




1,6051235








  • 2




    That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
    – TripeHound
    Nov 26 at 14:50






  • 1




    That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
    – Tommy
    Nov 26 at 15:35








  • 1




    @Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
    – BlackJack
    Nov 27 at 12:29










  • @BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
    – Tommy
    Nov 27 at 14:34










  • @Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
    – BlackJack
    Nov 27 at 14:39














  • 2




    That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
    – TripeHound
    Nov 26 at 14:50






  • 1




    That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
    – Tommy
    Nov 26 at 15:35








  • 1




    @Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
    – BlackJack
    Nov 27 at 12:29










  • @BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
    – Tommy
    Nov 27 at 14:34










  • @Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
    – BlackJack
    Nov 27 at 14:39








2




2




That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
– TripeHound
Nov 26 at 14:50




That's exactly how I read those warnings. The disk-drive (and its "self-contained" OS) hasn't closed the files; bits you think you've written may still be in buffers (and, depending on what you do next, may never make it to disk). Reopening one of those "orphaned" files may carry on where you left off or may mix new writes with old, buffered writes in (effectively) unpredictable ways. As King Lear said: that way madness lies!
– TripeHound
Nov 26 at 14:50




1




1




That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
– Tommy
Nov 26 at 15:35






That being a reasonable guess, I'm not sure that failure to flush a buffer is necessarily a problem on the 1541 — with just 2kb to work with, it pretty much just transcodes data and writes it straight out. I'd dare imagine the more likely risk is failure to update catalogues and indexes? (EDIT: and the general disconnect between internal BASIC state and that which it has communicated to the device, I guess, since maybe your floppy drive isn't a 1541 and has some real buffering going on, but this question is re: the 1541 and its manual only)
– Tommy
Nov 26 at 15:35






1




1




@Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
– BlackJack
Nov 27 at 12:29




@Tommy The1541 uses 254 bytes of data per block on disk and only writes whole blocks, so there is buffering going on and there is a high probability of data in the last block being lost if the file isn't closed properly. At least for sequential files. Which is the majority of files. Of course not updating the block availibility map (BAM) on disk is also a problem as there may be blocks associated with a file but still marked as free in the BAM. Not updating the directory entry is a good thing, because there is a flag indicating not properly closed files, so the user can see there is a problem.
– BlackJack
Nov 27 at 12:29












@BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
– Tommy
Nov 27 at 14:34




@BlackJack I feel like PRGs are the majority of files, but stand corrected otherwise.
– Tommy
Nov 27 at 14:34












@Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
– BlackJack
Nov 27 at 14:39




@Tommy With „sequential files“ I meant the structure from the DOS' point of view. There is no real difference between PRG and SEQ except the type info in the directory entry.
– BlackJack
Nov 27 at 14:39










up vote
7
down vote













In what might be borderline as acceptably a separate answer from paxdiablo, cf. the 1541 ROM disassembly. It's fully commented, so the following comments are a companion's guide to draw your attention to what I think are the relevant bits, see the full thing for a more thorough treatment.



The main dispatch loop, which listens to the serial bus and acts upon incoming commands, starts at E85B. Notice at E8CE that it'll segue to DAC0 if a CLOSE is received.



That code treats 15 as a special case — if that's received it'll just count down from 14 to 0 calling close file on each; that's the loop that is seeded at DAEC and then consists of DAF0, DAF3 and DAF5. For any regular channel it jumps straight to the close file routine.



The close individual file routine is at DB02 but an immediate corollary:




  • the ROM itself treats a request to close all as a simple sequence of CLOSE 14, CLOSE 13 ... CLOSE 0. The outer loop doesn't check whether the files are open, and it ends up at exactly the same place as if you'd typed CLOSE X. Therefore one can assume a priori that it is safe to close files that aren't open.


One doesn't really need to assume though; check out the test from DB04: is there actually anything associated with this channel? If not, stop harmlessly.



Re:




all files are CLOSED in BASIC, without CLOSEing them on your disk drive! This is a very dangerous condition.




and the implication that CLOSEing does something meaningful on the disk drive, skip ahead to DB20. From there there's a sequence of:




  • write last block;

  • write entry in directory and block;

  • write BAM (the table of which blocks on the disk are unoccupied);

  • close channel and exit this routine.


Followed by a separate:




  • get buffer number;

  • write block.


The various selection parts between DB04 and DB20 just make a selection about which of those they start with. But all paths go through at least one 'write'; specifically:




  • the last block and directory are skipped if you're involved in direct access, i.e. not performing file operations; and

  • the get buffer number/write block path is taken, ignoring the directory and BAM, if you're dealing with a REL file, which are specially allocated to be contiguous so there's no further global bookkeeping once the thing exists.


So for non-REL files, failure to close may lead to the data at the end potentially being missing, and the directory and BAM not being updated.



For REL files, failure to close may lead to the particular section of the file you were working on not being updated.



Re: attempting to write to a file that isn't open, start at CFF1; that jumps to C1C8 if no such file is open, which does as you expect by heading off to E645 harmlessly to report an error.






share|improve this answer



















  • 2




    Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
    – Tommy
    Nov 27 at 20:15








  • 2




    Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
    – paxdiablo
    Nov 27 at 21:32















up vote
7
down vote













In what might be borderline as acceptably a separate answer from paxdiablo, cf. the 1541 ROM disassembly. It's fully commented, so the following comments are a companion's guide to draw your attention to what I think are the relevant bits, see the full thing for a more thorough treatment.



The main dispatch loop, which listens to the serial bus and acts upon incoming commands, starts at E85B. Notice at E8CE that it'll segue to DAC0 if a CLOSE is received.



That code treats 15 as a special case — if that's received it'll just count down from 14 to 0 calling close file on each; that's the loop that is seeded at DAEC and then consists of DAF0, DAF3 and DAF5. For any regular channel it jumps straight to the close file routine.



The close individual file routine is at DB02 but an immediate corollary:




  • the ROM itself treats a request to close all as a simple sequence of CLOSE 14, CLOSE 13 ... CLOSE 0. The outer loop doesn't check whether the files are open, and it ends up at exactly the same place as if you'd typed CLOSE X. Therefore one can assume a priori that it is safe to close files that aren't open.


One doesn't really need to assume though; check out the test from DB04: is there actually anything associated with this channel? If not, stop harmlessly.



Re:




all files are CLOSED in BASIC, without CLOSEing them on your disk drive! This is a very dangerous condition.




and the implication that CLOSEing does something meaningful on the disk drive, skip ahead to DB20. From there there's a sequence of:




  • write last block;

  • write entry in directory and block;

  • write BAM (the table of which blocks on the disk are unoccupied);

  • close channel and exit this routine.


Followed by a separate:




  • get buffer number;

  • write block.


The various selection parts between DB04 and DB20 just make a selection about which of those they start with. But all paths go through at least one 'write'; specifically:




  • the last block and directory are skipped if you're involved in direct access, i.e. not performing file operations; and

  • the get buffer number/write block path is taken, ignoring the directory and BAM, if you're dealing with a REL file, which are specially allocated to be contiguous so there's no further global bookkeeping once the thing exists.


So for non-REL files, failure to close may lead to the data at the end potentially being missing, and the directory and BAM not being updated.



For REL files, failure to close may lead to the particular section of the file you were working on not being updated.



Re: attempting to write to a file that isn't open, start at CFF1; that jumps to C1C8 if no such file is open, which does as you expect by heading off to E645 harmlessly to report an error.






share|improve this answer



















  • 2




    Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
    – Tommy
    Nov 27 at 20:15








  • 2




    Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
    – paxdiablo
    Nov 27 at 21:32













up vote
7
down vote










up vote
7
down vote









In what might be borderline as acceptably a separate answer from paxdiablo, cf. the 1541 ROM disassembly. It's fully commented, so the following comments are a companion's guide to draw your attention to what I think are the relevant bits, see the full thing for a more thorough treatment.



The main dispatch loop, which listens to the serial bus and acts upon incoming commands, starts at E85B. Notice at E8CE that it'll segue to DAC0 if a CLOSE is received.



That code treats 15 as a special case — if that's received it'll just count down from 14 to 0 calling close file on each; that's the loop that is seeded at DAEC and then consists of DAF0, DAF3 and DAF5. For any regular channel it jumps straight to the close file routine.



The close individual file routine is at DB02 but an immediate corollary:




  • the ROM itself treats a request to close all as a simple sequence of CLOSE 14, CLOSE 13 ... CLOSE 0. The outer loop doesn't check whether the files are open, and it ends up at exactly the same place as if you'd typed CLOSE X. Therefore one can assume a priori that it is safe to close files that aren't open.


One doesn't really need to assume though; check out the test from DB04: is there actually anything associated with this channel? If not, stop harmlessly.



Re:




all files are CLOSED in BASIC, without CLOSEing them on your disk drive! This is a very dangerous condition.




and the implication that CLOSEing does something meaningful on the disk drive, skip ahead to DB20. From there there's a sequence of:




  • write last block;

  • write entry in directory and block;

  • write BAM (the table of which blocks on the disk are unoccupied);

  • close channel and exit this routine.


Followed by a separate:




  • get buffer number;

  • write block.


The various selection parts between DB04 and DB20 just make a selection about which of those they start with. But all paths go through at least one 'write'; specifically:




  • the last block and directory are skipped if you're involved in direct access, i.e. not performing file operations; and

  • the get buffer number/write block path is taken, ignoring the directory and BAM, if you're dealing with a REL file, which are specially allocated to be contiguous so there's no further global bookkeeping once the thing exists.


So for non-REL files, failure to close may lead to the data at the end potentially being missing, and the directory and BAM not being updated.



For REL files, failure to close may lead to the particular section of the file you were working on not being updated.



Re: attempting to write to a file that isn't open, start at CFF1; that jumps to C1C8 if no such file is open, which does as you expect by heading off to E645 harmlessly to report an error.






share|improve this answer














In what might be borderline as acceptably a separate answer from paxdiablo, cf. the 1541 ROM disassembly. It's fully commented, so the following comments are a companion's guide to draw your attention to what I think are the relevant bits, see the full thing for a more thorough treatment.



The main dispatch loop, which listens to the serial bus and acts upon incoming commands, starts at E85B. Notice at E8CE that it'll segue to DAC0 if a CLOSE is received.



That code treats 15 as a special case — if that's received it'll just count down from 14 to 0 calling close file on each; that's the loop that is seeded at DAEC and then consists of DAF0, DAF3 and DAF5. For any regular channel it jumps straight to the close file routine.



The close individual file routine is at DB02 but an immediate corollary:




  • the ROM itself treats a request to close all as a simple sequence of CLOSE 14, CLOSE 13 ... CLOSE 0. The outer loop doesn't check whether the files are open, and it ends up at exactly the same place as if you'd typed CLOSE X. Therefore one can assume a priori that it is safe to close files that aren't open.


One doesn't really need to assume though; check out the test from DB04: is there actually anything associated with this channel? If not, stop harmlessly.



Re:




all files are CLOSED in BASIC, without CLOSEing them on your disk drive! This is a very dangerous condition.




and the implication that CLOSEing does something meaningful on the disk drive, skip ahead to DB20. From there there's a sequence of:




  • write last block;

  • write entry in directory and block;

  • write BAM (the table of which blocks on the disk are unoccupied);

  • close channel and exit this routine.


Followed by a separate:




  • get buffer number;

  • write block.


The various selection parts between DB04 and DB20 just make a selection about which of those they start with. But all paths go through at least one 'write'; specifically:




  • the last block and directory are skipped if you're involved in direct access, i.e. not performing file operations; and

  • the get buffer number/write block path is taken, ignoring the directory and BAM, if you're dealing with a REL file, which are specially allocated to be contiguous so there's no further global bookkeeping once the thing exists.


So for non-REL files, failure to close may lead to the data at the end potentially being missing, and the directory and BAM not being updated.



For REL files, failure to close may lead to the particular section of the file you were working on not being updated.



Re: attempting to write to a file that isn't open, start at CFF1; that jumps to C1C8 if no such file is open, which does as you expect by heading off to E645 harmlessly to report an error.







share|improve this answer














share|improve this answer



share|improve this answer








edited Nov 27 at 19:57

























answered Nov 27 at 19:45









Tommy

13.6k13466




13.6k13466








  • 2




    Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
    – Tommy
    Nov 27 at 20:15








  • 2




    Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
    – paxdiablo
    Nov 27 at 21:32














  • 2




    Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
    – Tommy
    Nov 27 at 20:15








  • 2




    Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
    – paxdiablo
    Nov 27 at 21:32








2




2




Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
– Tommy
Nov 27 at 20:15






Meta aside: I argued myself into this being worthy of posting as a separate answer since I took the time to locate and index the authoritative source material, even though it's just a heavily-referential way of getting to the same answer as paxdiablo has already posted, and which I had previously read. Maybe that's valid reasoning, maybe it's not. Please don't hesitate to tick as community wiki and/or merge into paxdiablo's work if anybody thinks there's even just a spirit-of-the-thing fair play violation here.
– Tommy
Nov 27 at 20:15






2




2




Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
– paxdiablo
Nov 27 at 21:32




Tommy, there's nothing the least bit borderline unacceptable about this answer. You have provided more info than I did about the WHY of why it might be bad to close improperly. Kudos for the extra effort.
– paxdiablo
Nov 27 at 21:32


















draft saved

draft discarded




















































Thanks for contributing an answer to Retrocomputing Stack Exchange!


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.





Some of your past answers have not been well-received, and you're in danger of being blocked from answering.


Please pay close attention to the following guidance:


  • Please be sure to answer the question. Provide details and share your research!

But avoid



  • Asking for help, clarification, or responding to other answers.

  • Making statements based on opinion; back them up with references or personal experience.


To learn more, see our tips on writing great answers.




draft saved


draft discarded














StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fretrocomputing.stackexchange.com%2fquestions%2f8384%2fwhat-is-the-danger-involved-in-trying-to-write-already-closed-file-with-commodor%23new-answer', 'question_page');
}
);

Post as a guest















Required, but never shown





















































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown

































Required, but never shown














Required, but never shown












Required, but never shown







Required, but never shown







Popular posts from this blog

Сан-Квентин

8-я гвардейская общевойсковая армия

Алькесар