Changing date/time of a Directory

With Ref to changing date/time of a Directory ie
using below to create a directory.
SYS"OS_File",8,“hostfs:nonsuch”

Then using – to set the Dir date/time

SYS"OS_File"3,“hostfs:nonsuch”,,&269e4dbf

This seems to work with ADFS/MEM.
Does it work with other filing systems?
Is it only not working with VRPC hostfs?
Is there another way of setting the date/time of a Directory?
Thanks

Is there another way of setting the date/time of a Directory?

Surely that’s what OS_File 9 is for?

I was using OS_File 3 – for changing the date/time.

Doesn’t seem to work with VRPC ‘HostFS’ – this is used as part of Sib7 copy protection.

Does ‘OS_File 3’ work with the new machines filing systems?

Files can be updated ok – using this command with HostFS.

The ‘Filer window’ updates when the swi is called – so perhaps it is supposed to work.

Is there a way of following the swi through to test it?
Thanks

Have you tried with the other VRPC filing system ie the ADFS image filing system?
I suspect the HostFS problem may be because it is really using the facilities of the underlying Windows Filing system (probably NTFS) which does impose some differences. More to do with the emulation rather than RISC OS.

I havn’t a ADFS partition set up – but RamFS works as does MemFS.
HostFS will update a file – and if I modify Sib7 to use a File instead of a Dir – it works – but it means modifing the !RunImage – which brings other problems.

The hostfs module in RPCEmu (as at 0.8.14) does not attempt to write any catalogue information for directories – there is a ‘TODO FileCore systems usually handle this’, so OS_File 1,2,3,4 and their friends won’t work. Don’t know about VRPC hostfs.

Note: Definitely not an expert at all.
I referenced OS_File 9 purely because that is specifically labelled in the PRM’s as date / time stamp change, but if you compare the actions of OS_File 3 and 9 then OS_File 3 only amends the execution address metadata while OS_File 9 amends both execution address and load address metadata.
It may affect what gets passed through to the Windows filing system.

If OS_File 9 does not work on VRPC HostFS, but does on VRPC ADFS, RamFS and MemFS, then I suggest the question is asked on the VRPC forum or mailing list.

HostFS is part of VRPC, not RISC OS. Difficulties may be because NTFS has 8 timestamps for each file & directory, and working out which is the right one to use to emulate the single RISC OS timestamp is not simple. Also how to use it has to take into account the differing ways of handling GMT vs local, summerime, territories, etc. HostFS may just avoid the issues!

Resurrecting a very old thread because it’s perfectly relevant…

I’ve been unable to get OS_File 9 to work on SCSIFS or RAMFS, whereas calls to OS_File 2 followed by OS_File 3 work perfectly.

I was “banging my head against a brick wall” for hours, thinking this has to work. It doesn’t, but the alternative works perfectly.

RO 5.29 (11-Feb-24), RPi 3B+.

OSFILE 3 writes the exec address. The datetime stamp is held in the load and exec addresses, so just writing the exec address will only write the bottom 32 bits of the datetime stamp. You should use osfile 9,filename,load,exec where load=&FFFtttdd bits 32-39 of datetime, exec=&dddddddd bits 0-31 of datetime.

If that does not work, the fallback is: osfile 5, change load/exec, osfile 1, or as Dave’s found, set load and then exec seperately. If that doesn’t work, the underlying filing system is not supporting it. There are some filing system implementations that do not like setting metadata on directories.

OS_File 9 was specified to be ‘Date stamp file’, not ‘Date stamp object’. In Arthur/RO2 it used to do (internal)OS_File 5, change load/exec (to reflect current date time), (internal)OS_File 1 as JGH suggests for fallback, giving an appropriate error if the object was not a file.

I have been trying to date stamp a file. Can a few volunteers please try it and post the results here – does it work?

But thank you for the reminder of the distinction.

I have just tried OS_File,9 on a file and a directory on: RAMFS, ADFS, SDFS, LanManFS and LanMan98. It seems to work on all of them.
But that sets the timestamp to the current time – are you asking about setting it to a specific time?

I think https://www.riscosopen.org/wiki/documentation/show/OS_File%209 is misleading re. use of R2,R3.

Comment in my old source is “; Set datestamp on file to current”

I see someone has commoned up StampFileOp and SetTypeFileOp into StampSetTypeFileOp (https://gitlab.riscosopen.org/RiscOS/Sources/FileSys/FileSwitch/-/blob/master/s/OSFile#L390) – in RISC OS 3 perhaps? Does it do what the two separate functions did? Who knows.

I found setting date and time to be a pain so added the facility for !MultiTask to datestamp a file or a zip archive (while SparkFS not running). Uses a menu structure to choose the date and time.

So dragging a file to the MultiTask window allows the date and time to be selected from a menu:

Directories are more complicated. Application directories display the date of the !RunImage file inside them, not the datestamp of the directory.

On VRPC the HostFS filing system uses one of three dates (created, altered or last accessed) that Windows uses.

But that sets the timestamp to the current time – are you asking about setting it to a specific time?

Comment in my old source is “; Set datestamp on file to current”

Ah… now I see, thank you to all.

I’ve updated the wiki entry for OS_File 9.

No wonder I couldn’t reconcile the paper PRM with the wiki. I note that the paper PRM doesn’t actually mention that it’s the current date/time; it must just assume it because there’s no way to specify anything.

And in response to the original question:

Is there another way of setting the date/time of a Directory?

OS_File 2 followed by OS_File 3 to set the load and exec addresses. Works on files and directories, it appears.

Better late than never?

After the various comments regarding how to set the timestamps on files and directories, I thought I would try to understand a complete picture of what worked and what did not.

I created a little test program, which for each directory to test, it:

• Creates a file and a directory.
• Uses OS_File,1 to set timestamp to 01:01:01 01/01/2001
• Uses OS_File,2/3 to set timestamp to 12:12:12 12/12/2012
• Uses OS_File,9 to set timestamp to new current time.

After each stage it uses *Info to display the timestamps.
The output is the results for several directories.

I ran this on…

• Titanium with RO5.29 using RAMFS, ADFS, SDFS, LanMan, LanMan98 and Fat32FS.
• VRPC with RO4.39 using RAMFS, HostFS and ADFS.
• RPCEmu with RO4.39 using RAMFS, HostFS and ADFS.

My conclusions are that all methods changed the timestamp on all machines using:

• ADFS, RAMFS, and SDFS.
• LanMan and LanMan98 (to a Synology NAS)
• Fat32FS.
• HostFS (both VRPC and RPCEmu) but only Files

However, using HostFS (both VRPC and RPCEmu) directories do NOT change.
I suspect this is do do with the underlying file system.

If anyone wants to try out my StampTest program, it can be downloaded
from http://www.avisoft.f9.co.uk/downloads/StampTest011.zip

@Chris; Please use a dialog to set the datestamp rather than SIX nested menus. Apart from being totally less horrid it would the option to retain the last datestamp set, so you can easily repeat the operation on a subsequent file.

@Martin: See my earlier comment “The hostfs module in RPCEmu (as at 0.8.14) does not attempt to write any catalogue information for directories – there is a ‘TODO FileCore systems usually handle this’, so OS_File 1,2,3,4 and their friends won’t work.”

Furthermore, as this is one that caught me out so I thought I’d mention it for completeness…

…you cannot modify the type of an open file.
Works perfectly fine on RISC OS, but under emulation this may cause the file extension to change and then hilarity ensues.

@Chris; Please use a dialog to set the datestamp rather than SIX nested menus.

My only defence is laziness. It was far quicker to set up a menu structure than to do a window with up and down buttons for each item. When I get time I’ll do it properly. It is surprisingly quick to navigate the menus – no need to open minutes or seconds if you want them to be zero.

I’m not so sure it’s not a good approach. From decade down to the minute, how would you do it more efficiently?

My phone has a good approach for time of day that only takes two “clicks”, to the minute.

Setting an arbitrary time and date that is somewhere between 1 Jan 1990 and (say) 2025 is going to take more than two clicks!

My phone has a good approach for time of day that only takes two “clicks”, to the minute

Some finger rolling and two taps can set the time with ease.

Setting a date can be rather more complicated.

And some of those pop-ups you get on websites for date, oh my god. There’s no shortcut on some of them for the year. Just forward and back for the month. When it is asking for a date of birth…
Sometimes it’s just easier to write it.