Can't open T/Command-0-T1

[rvo_nl]

Hi all! It's been some time, have had a lot of (hardware related) bad luck with my machine the last year and am really giving it a last chance before I give up. However, this question is software related so no guesswork needed

I have a machine that boots up from a FFS hd0 partition, runs a little script that asks me to boot OS3.9, OS4.1 or plain WB3.1, sets some assigns, then executes the right startup-sequence. This has worked flawless for many years. Please don't question the script.

Yesterday however, I made the stupid mistake of deleting a folder called T on that hd0 partition, figured I didnt need it. Inside was just one file, called Command-0-T1 or something. After that, my machine refuses to run its script. Everytime I choose to boot OS3.9, it tries to execute the startup-sequence on that drive, then fails with the message:

EXECUTE: Can't open ":T/Command-0-T1"
object already exists
execute failed returncode 10

Just what is it trying to tell me?! Ofcourse I've tried putting a T folder back, fiddling with permissions on that folder. I've tried restoring an old backup, tried even salvaging data using Disksalv, but nothing is working. What does it want? Surely someone must know?

[guest11527]

Yesterday however, I made the stupid mistake of deleting a folder called T on that hd0 partition, figured I didnt need it. Inside was just one file, called Command-0-T1 or something. After that, my machine refuses to run its script. Everytime I choose to boot OS3.9, it tries to execute the startup-sequence on that drive, then fails with the message:

EXECUTE: Can't open ":T/Command-0-T1"
object already exists
execute failed returncode 10

Just what is it trying to tell me?!

If "execute" is called on a script that takes parameters, it needs to go through a temporary file - essentially, it parses the script and runs the parameter substitution. For this, it first tries to create a file in "T:" and, failing that, in ":T/". The error you see indicates that it cannot create this file. Either because ":T" is not a directory, but a file, or because it cannot create ":T/T-Command-0-T1" for writing.

You can check yourself by listing ":T" in the shell, or trying to write to this file yourself, i.e. by a simple echo:

Code: [Select]

echo "test" >:T/T-Command-0-T1 and check what happens. Probably ":" is not quite what you think what it should be.

Just a recommendation: I would probably not put an execute like this into the startup-sequence. In case the disk is validating, execute is requiring a write access to the disk, which then either fails, or at least potentially destroys an already destroyed disk even more. Execute is ok after a couple of precautions, namely: a) SetPatch is already run, b) the RAM-disk has been mounted, and c) T: has been assigned to a directory in RAM:. Then, execute can no longer touch your disk.

[kolla]

It has always pussled me why :T is used rather than just RAM: when T: is not assigned. Personally I would have made both T: and CLIPS: into kickstart as tiny ramdisks akin to HappyENV/env-handler, so they would be already present on boot.

[Thomas]

It has always pussled me why :T is used rather than just RAM: when T: is not assigned.

Because RAM-Handler originally was disk-based and didn't need to be present.