On 2013-01-07, at 14:00, Greg King wrote: >> ... Funny enough, I >> never encountered that bug before. > > This issue fits into that famous quote, "It's a feature, not a bug." > I think that the purpose is to help us avoid making "splat" files. Well.. I guess I should be grateful then for the help they provided me rather than whine about the bugs ;-) > A "well-written" program checks the result status of all disk operations -- including file-closings. Therefore, the status file should be open for as long as any data file is open. So, the tradition has been: Open the command & status file first; and, close it last. Well written program may as well check for C flag on return, which is a sort of convention with many KERNAL routines. Unfortunately somebody "forgot" to add this to e. g. OPEN call. > I suspect that you had not seen that command-channel behavior before now because you always had done that tradition -- before now. You are very much right! But there were also reasons for that. First, back in the days I had one drive and if someone had two, he was perceived as someone who doesn't know what to do with money ;-) This means I didn't really care about how many files I keep open because the drive itself limited me more than anything else. Second is that programming in a single-task environment didn't call for releasing resources ASAP. This came to me later. Today, a) being well used to immediate release of resources and b) having to deal at the same time with three (each different) drives, uIEC, IDE64 (with two filesystems mounted) means that keeping command channel open for all of them (yes - that's the case here) leaves hardly any room for actual data files being open on them.. Anyway - this is quite OT here. I just recalled a part of older thread upon discovering that behaviour... ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Tue Jan 8 23:08:32 2013
This archive was generated by hypermail 2.1.8 : 2013-01-08 23:08:35 CET