Open file for write but it's not writable
Dave Higton (1515) 3404 posts |
I noticed yesterday that I could OPENOUT a file in BASIC, but not write to it because the file already existed and had attributes of &11. Does this sound logical or illogical to you? |
Rick Murray (539) 13401 posts |
I’m writing in a tablet in a car so can’t look up what attribute &11 is; however successfully using OPENOUT to create a file handle to an existing file that I presume is locked in some manner ought to fail surely? |
Rick Murray (539) 13401 posts |
Okay. RISC OS 5 is acting irrationally. :-)
A file that is not open for update should be faulted at the point of attempting to OPENOUT the file. The “R!” in the bottom line means the file is opened for read access, and that the file has been written to (but data not written to media). I cannot test with older versions of RISC OS. Just tried with RedSquirrel and RISC OS 3.70; however files one HostFS remain fixed at WR/WR privs no matter what is specified in a *Access command. Further:
Action &8x is supposed to create an empty file with read/write access. By what logic is it opening an existing file that is R/R attributes and providing read only access to it? |
Rick Murray (539) 13401 posts |
Ah… The nastiness of it is buried in the PRMs (P2-78 (p88 actual) in my DDE copy):
OMG. What a farce. Thankfully SDFS doesn’t do the moronic action of setting the extent of an R/R file to zero. But that an OS call intended to open a file with read/write access can’t even manage that competently – what is this, DOS? :-/ Serious question: File is read only. User wants to create anew with read/write. Why doesn’t it fail? |
Jeff Doggett (257) 231 posts |
I fell foul of this in FAT32FS. |
André Timmermans (100) 620 posts |
I Jeff, I noticed that on Fat32FS each time I open an archive, its date changes to the current date. This does not occur on other filing systems. |
Chris Hall (132) 3501 posts |
I think it does happen on some other filing systems, SCSI I think. |
Jeff Doggett (257) 231 posts |
Hmmm, I guess that RiscOS closes the file with a timestamp and FAT32FS is simply passing this on without checking that the file was actually written to. I won’t have time to look into this properly for a few days. |
Chris Hall (132) 3501 posts |
I think if you use SparkFS R/o it leaves the filestamp alone. Windows does the same – if you open a file it changes the datestamp but when you close it without saving any changes it reverts back to what it should be. One possibility is that if you look into the archive, the zip file must be opened. At that stage the SparkFS r/w does not know whether you intend to read or change things. OPENUP would thus be used in place of OPENIN as it can’t close it and reopen it as you may have files open by then. Unless SparkFS notes whether you change anything and remembers the filestamp and restores it on closure if nothing has changed, default behaviour would be to update the datestamp… If find this extraordinarily annoying if I want to look into an archive but don’t want to alter the datestamp. Copying it to RAMdisc first is not something I always remember to do. |
Jeff Doggett (257) 231 posts |
I’ve made some changes to Fat32fs – well ok, I’ve fixed the bugs that prevented it from working as expected! |