How's the whole read-only read-write thing work?

Okay, every once in a while I'm messing at the shell prompt and I get that error which tells me I've been a bad boy and didn't set things to read-only after I was done with 'em. But I know that I did.

I wonder if it's related to this...

I often use the Hijack web interface to set the player to read-write and read-only, using the commands http://empeg/?rw&NODATA and http://empeg/?ro&NODATA , and then watching the screen to make sure it responds appropriately.

But just now I set the player to read-write with the HTTP command, then I went to the shell via serial and Q'd out of the player. Got the BASH prompt, all was fine.

And then tried to do something at the shell prompt and it complained that the filesystem was read-only. But I'd just set it read-write!

Does the player try to set things read-only when it exits out to the BASH prompt or something? And perhaps maybe it only sets one thing read-only and not the other? And when I try to use hijack in this half-state, things go wonky?

Who sets what read-only and when?

Yes, and yes.

I think there are even messages on the console when 'q'-ing from the player to that effect.. But no empeg here to verify with. Anyone?

Cheers

Greetings!

Correct. When you exit the player application to shell, it will set everything to read only. This includes when you run the player application from command line.

Yes, there are messages on the console when Hijack does its thing.

Is there a chance I could mess up stuff by using Hijack to set RW, then exiting to the shell, then using the shell commands to set it RO?

You should not be able to mess things up by setting back and forth. The only time you should get into trouble is if you inadvertently power off while in read/write mode.

All you are doing with the RO command would be to remount it as read only. You can do so repeatedly, and it will not cause any trouble. All you might do (if you do it a lot) is increase the mount counter for the filesystem, so that if you are not suppressing that check through hijack, your syncs may decide to do an fsck based on the number of mounts.

Hmm, dunno then.

Thanks for the info.

Which error do you get? The maximum count or the unchecked fs?

Edit: Aha! You are right. Exiting the player only sets the music partitions read only. So at this point, your root partition is read/write, but your music partitions are read/only. Which partition were you getting that error on?

Greetings!

And if you exit / restart the player in this state, even if it is the root partition, it will mark that you have done something bad and make you fsck.

Which error do you get? The maximum count or the unchecked fs?

The unchecked FS, the "I've been a bad boy" error.

Which partition were you getting that error on?

I don't remember which it was, I just remember having gotten the error in the past.

But let's say, hypothetically, that I'd used hijack for one thing and the player software for the other thing (again, don't remember which).

Do you think there might be a chance that there would become a desynchronization? Such that when I tell the player software to mount RO, it either doesn't do it because it doesn't know Hijack has set one or both to RW, or it thinks it already did so when it exited (but it only ends up doing so on the one because it only thinks it needs to do one)?

Hmm...

I am not certain what hijack is doing. I assume that it is mounting the / and the music partitions in tandem according to whatever you select.

The shell commands RO will do both the / and music partitions, RW, ROM and RWM will only do their appropriate partitions (/ or music).

Exiting the player application will set the music partitions read/only, and not change the state of /.

The only thing that you have to watch for is that /programs{0,1} parititions are set rw/ro by hijack, but not by the player software. This is because hijack remounts all currently mounted filesystems whereas the player software uses shell scripts that only know about official empeg partitions,
Of course, this only affects those who have the /programs{0,1} partitions formatted to begin with. Editing the ro shell script to ensure that these partitions would get remounted ro in these circumstances would be trivial.

I don't have programs0/1 any more, so that's not the issue with me.