Hi Theo,
I have noticed similar behaviour when copying large trees to a sparkfs
archive. Almost seemingly at random files appear to be 'in use' this
is with rpcemu spoon 0.8.4 To me this is 'new' behaviour. Not sure
what causes it..
Jan Rinze.
Op 13 jun 2009 om 03:01 heeft Theo Markettos <[email protected]>
het volgende geschreven:\
I've been trying to build the ROOL sources on RPCEmu, having them
mounted as
a Samba share on the Linux host from another Linux machine. I've run
into a
bug in EmuFS (svn167, RO4.39, dynarec).
Very simply demonstrated:
F%=OPENOUT("Test")
P.F%
251
F2%=OPENOUT("Test")
P.F2%
34662412
P.~F2%
210E80C
Address &210E80C contains the equivalent of:
.&0210E80C
DCD 0001BEC2
DCS "This file is already open"
DCB 0
So, evidently, the V flag isn't being set on return from the EmuFS
module.
But I tried, in BASIC in User mode, the code snippet in EmuFS that
sets the
V flag and that's fine:
error_generate:
teq r0, r0 @ Set Z, so pc as
operand 1
and 2 will be
different in 26 bit user mode
teq pc, pc
orrnes pc, lr, #VBIT @ Return with V set,
caller
flags preserved (26
bit mode)
msr cpsr_flg, #VBIT @ Set V current flags
preserved
mov pc, lr @ Return error
function with
V set, caller flags
corrupted (32 bit mode)
(MSR is &E328F201 as BASIC can't assemble it. The code in EmuFS is
bit-for-bit the same as the code that BASIC assembled)
And that's the last the EmuFS module does before returning to
FileSwitch...
so I don't see how it could fail to be passed on. Since the
MessageTrans
lookup has happened the V flag has obviously been passed through
from the
host code.
I tried this in assembler:
ADR R1,test
MOV R0,#&8C
SWI "XOS_Find"
MOV PC,R14
.test
DCS "Test"
DCB 0
And lookend at the status before calling MOV PC,R14 (with a
breakpoint): R0
points to the error message but the V flag isn't set. So it's
nothing to do
with BASIC being odd.
Unless there's some problem with the V bit setting in supervisor
mode I'm a
bit stuck. Ideas?
Theo
(I don't think this is actually what's been annoying the ROOL build
though -
looks like we're failing to write to existing files at all, even
ones that
have been opened for the first time. Only seems to happen on the
Samba
share, even though Linux can write just fine, as can RISC OS on
occasion)
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
_______________________________________________
Rpcemu mailing list
[email protected]
http://www.riscos.info/cgi-bin/mailman/listinfo/rpcemu
