Login and other Timestamps stored?

Hello,

I wanted to know where are things such as login time stamps, file creation, etc stored in RISC OS?

I had a read of Rick Murray’s post regarding multiuser OS. I initially wanted to know how to know timestamps of different users on RISC OS, but reading that post, am I right to believe that RISC OS is not a multiuser OS?

Thanks in advance.

RISC OS has no concept whatsoever of users. As such, it also has no login procedure; you simply boot RISC OS and off you go – you are effectively the superuser. The only slight concession towards the concept of users is in the file system, where there is a distinction between the local read & write access permissions and the remote (public) read & write permissions. This only really has an effect for network file systems, to control in a very basic way what remote users can see and do with your stuff.

As for file creation timestamps, the standard RISC OS file systems hold metadata along with each object (file, directory, image) and one of those items of metadata is the timestamp. This is the time at which the file was last modified. There is no ‘creation’ timestamp held alongside that. Other file systems (network filing system clients, like NFS for example) will abstract over whatever is at the remote end to present things in the RISC OS style.

See this page for an example of the metadata that is stored with each file system object – note: the “load” and “execution” addresses (32 bit unsigned integers) tend to actually contain some other metadata for your average file. (Note: it looks like that section of our wiki is incomplete.)

Oh I see.

You say it has no concept of users but does it store metadata like when the machine (Raspberry Pi in my case) was booted up/logged into?

lastly, now talking about the metadata of the files, how am i able to view that? Within RISC OS? Also, if I wanted to view that on Windows for example, is it possible?

You say it has no concept of users

Correct.

but does it store metadata like when the machine (Raspberry Pi in my case) was booted up/logged into?

Not normally, but it ought to be possible by appending <Sys$Date> and <Sys$Time> to a file by patching a couple of lines into the boot startup script. I won’t give an example, just turned my Pi off for the night. Cue the amazing Mr. Drain to show you how it’s done…

Is this something you need to know? Are you expecting it to be used when you don’t know?

now talking about the metadata of the files, how am i able to view that? Within RISC OS?

Usually in the filer, by reading the details of the selected file. From the command line, *Info <filename> will show much of the same stuff.

Also, if I wanted to view that on Windows for example, is it possible?

There is no way to get a RISC OS file into something Windows can read without screwing up the metadata. We don’t support NTFS and FAT’s permissions are laughable. I think the date/time might be copied, but given it’s a coin-toss between whether your FAT volume is using local time (pre-XP) or UTC time (XP and later, hopefully), that’s not so relevant either. FAT has no concept of filetypes whatsoever. Some types can be converted on our end (like .txt → &FFF ‘Textfile’) but for the majority, a comma-then-type suffix is about as good as we get – like !RunImage,ff8 which Windows won’t touch because it has no file extension (but, then, how many filetypes native to RISC OS are even useful on anything else?).

That’s not to say it is impossible to transport files around. I’ve just made an archive of ResFinder, popped it on a USB stick, and uploaded it to my site using WinSCP, under Windows…

lastly, now talking about the metadata of the files, how am i able to view that? Within RISC OS?

Pick yourself a file:
click the middle mouse button over the file, move to the file option in the menu, move to the info option in the sub-menu, read the information.

You say it has no concept of users but does it store metadata like when the machine (Raspberry Pi in my case) was booted up/logged into?

OS_ReadMonotonicTime returns the number of centiseconds since the machine was turned on, although I think its value can be tampered with by badly-behaved applications. There is no log of all the occasions on which it was turned on in the past, although an application which maintained one would be trivial to write.

lastly, now talking about the metadata of the files, how am i able to view that? Within RISC OS?

Are you actually suggesting that RISC OS would provide no way to view the time stamp and filetype of a file? Seriously?

Also, if I wanted to view that on Windows for example, is it possible?

That depends entirely on how you are planning to view it on Windows. Windows can’t read RISC OS-formatted media. There are a number of solutions available to transfer files from RISC OS to Windows, all of which preserve the time stamp, and almost none of which preserve the filetype.

The problem of Windows discarding the filetype metadata is one which bites most newbies at least once. RISC OS software will cease to work if it is allowed to get ‘infected’ by storage on a Windows device. The most common workaround is to transfer files in Zip format, which has special fields allocated in its specification for RISC OS purposes – however, this only works if the archive is both created and extracted on a RISC OS machine. Decompressing software you downloaded on Windows before transferring it to RISC OS will cause the filetype metadata to be lost.

EDIT: Double ninja!

UTC time (XP and later, hopefully)

Allow me to crush that hope, just for reality’s sake. Even Windows 8 is still on local time by default.

http://superuser.com/questions/494432/force-windows-8-to-use-utc-when-dealing-with-bios-clock

RISC OS has no concept whatsoever of users.

Then what is the directory HostFS::HardDisc4.$.!Boot.Choices.Users.Single for then? Just unnecessary complication or what?

oo interesting thread.

Now me being a complete newbie to RISC OS, how would I look at time stamps on my machine (Windows 7)? Coming from a forensic background, I could image it using Encase, but would that give me all the info? Because when I imaged it some time ago, it was giving me a lot of allocated clusters? (don’t know if it’s worth asking here or should i create a new thread?)

Sam.

RISC OS has no concept whatsoever of users.

Then what is the directory HostFS::HardDisc4.$.!Boot.Choices.Users.Single for then? Just unnecessary complication or what?

Isn’t that a RISC OS 4/6 only path? IIRC it was for future plans to have multi-user & the future failed to arrive.

Now me being a complete newbie to RISC OS, how would I look at time stamps on my machine (Windows 7)? Coming from a forensic background, I could image it using Encase, but would that give me all the info? Because when I imaged it some time ago, it was giving me a lot of allocated clusters? (don’t know if it’s worth asking here or should i create a new thread?)

As I understand it, Encase makes a complete bit-for-bit image of the disc. So yes, that would give you all the information you need in order to read the timestamps (If not, then Encase is pretty useless as a forensic tool!)

However I suspect that the developers of Encase won’t have taught it about the disc format (FileCore) that RISC OS uses. Otherwise I’m guessing your earlier analysis would have turned up something more useful than “a lot of allocated clusters”. So your mission (should you choose to accept it) is to track down the FileCore documentation and work out how to teach Encase to understand FileCore format discs. Apparently Encase has a scripting interface, so presumably that’ll be sophisticated enough for you to complete the task.

Note that up-to-date FileCore documentation might be a bit tricky to find, so you might have to start with the basics and then work your way up through all the new formats and extensions. RISC OS 3.1 era FileCore formats are documented in the RISC OS 3 PRMs (which can be viewed online or downloaded). Newer extensions to the format are only really documented here in the source tree.

RISC OS Select/Adjust and SIX do have some kind of “multi user system” insofar as there is a user selection/login on startup and these users have several separated paths inside !Boot to keep things like !Scrap and Choices apart. Probably the maximum “multi user appearance” to be achieved in RISC OS without shaking its foundations.

Probably the maximum “multi user appearance” to be achieved in RISC OS without shaking its foundations

Yes, the stuff on the ROL fork is little more than window dressing. You’re basically allowing different users to boot the machine up into a state that’s vaguely specific to them. It’s not adding any security and it’s not allowing concurrent use by multiple users. All of these changes, as Steffen hints, would require fundamental changes to RISC OS. Because fundamentally, it has no concept of users.

You may call it “window dressing” but it certainly did what some people wanted!

Thanks for your comments.

Jeffrey Lee, that is a whole project in itself :O lol But I got to get my head round this :/

Damn, why can’t things be simple for once bangs head against wall lol

On a serious note, It would be interesting to see if s file was placed on the disk (from windows), booting into RISC OS, and seeing what the metadata says about that file.

Seriously, to be able to ‘place a file on a disk from windows’ the disc needs to be a FileSystem that is writable by Windows.
For a disk to be bootable into RISC OS it needs to be a FileSystem that is readable by RISC OS.

What FileSystem are you proposing to use?

I am still unclear what you are trying to do. If you are trying to analyse the metadata of files on a RISC OS formatted disc, the data could be extracted by a RISC OS program very easily – even one written in BASIC! The data could be analysed on another machine.

You may call it “window dressing” but it certainly did what some people wanted!

That’s as may be, but it’s a far cry from RISC OS having multi-user support, which is the point I was making.