SAVE bug?
Chris Hall (132) 3558 posts |
On my Iyonix (both RISC OS 5.16 and 5.20) and using LanMan98 to save a file to my NAS, I find that the following command gives the file a spurious datestamp (always the same-ish date in April 2014): If I do an explicit *Stamp filename it gets the date right (as you would expect). Any ideas please? |
Chris Evans (457) 1614 posts |
I wasn’t aware there was an ‘unstamped’ status. What date 0000000 equals I don’t know I reserve the right to have grasped the wrong end of the stick! |
Steve Fryatt (216) 2105 posts |
There is: a stamped file has the top 12 bits of the load address set; if they’re not, it’s assumed to be a real load address. Chris’s example of &1000 wouldn’t fit the criteria of a stamped file. Of the remaining 20 bits, 12 are the filetype, and the other 8 are the most-significant 8 bits of the 5-byte datestamp (with the other 32 being stored in the execution address). IIRC *Save filename From+length execution_address load_address In Chris’s example, load and execution addresses will both be set to &1000, because they default to where the file was saved from.
&0000000000 (as datestamps are 40 bytes) is midnight on 1st January 1900 – except it isn’t, because the file is unstamped. If it were getting interpreted as a date, that &1000 would be 4096: less than a minute after midnight at the start of 1900. Not that this helps with Chris’s problem… It works OK on a recent SDFS, and 5.21 too. |
Jeff Doggett (257) 234 posts |
There’s the issue! Only filecore filing systems implement the 64 bit load/exec addresses. All others have to have valid dates. Fat32fs will have the same problem. |
David Pitt (102) 743 posts |
Here on the Iyonix OS5.20 and Pi OS5.21 LanMan98 2.05 Not that this helps with Chris’s problem either, which seems to be shortcoming RISC OS filetyping emulation on the remote file system. I don’t know how much use this might be but creating a zip with SparkFS on the NAS via LanMan98 opens a filer window to which the unstamped lxa file can be saved correctly. |