Post by Andrew Alexanderyeah like I said... FIRE BAD!
Post by d***@propg.comHowever don't assume that you can store the
file base on a native windows system. This can create other
problems
Post by Andrew AlexanderPost by d***@propg.comas well depending on the file base type. It's ok to have the actual
files stored in a windows partition, but no data files associated with
the file base should be on a windows drive. If you are not going to
have a huge file base, then I would just create some additional drive
image files and use them for everything.
Ok, well you can assume it since I know it works cus I ran my board for
well over a year in that mannor. File system issues only seems to effect
the big things like users and subboards... you know the things no system
can live without. It would be a good idea like you said to keep the data
file seperate which is easy to do... and just store the files in Windows
directories. This also gives you an easy way to bridge things over to
the hard drive files durring run time. Hard drive files over 500MB is
just not worth doing... fills up too fast... =(
I would suspect that your system was not using certain features that
would have created the problem. As I said it can be done, it just
needs to be setup properly. Plus if your file bases did not get very
big, then I would not have expected the files to get corrupted as there
is enougth slack in the disk interleave to account for small relative
data files, but not the larger ones. This is why your files would be
fine but your message bases would not be. In any case, let me know if
I need to post a detailed description of how to set this up properly.
Post by Andrew AlexanderMy tests... and your gonna love this... When the emulator starts up it
captures the nature of the Windows file system at that time. Free space,
used space, and total drive size. It seems as soon as Windows swap file
alters it's size the Emulated Amiga now has incorrect information on the
state of the hard drive and starts writting everything all screwy. Raw
files transfer great between the two... data writting is a mess though.
Once again, it not a factor of the emulator, it a factor of the two
incompatible file system. If it were a problem with the emulator then
I would expect WinUAE to fix it. But becase they can't change either
file system, they are stuck. An Amiga Relative Data Access file will
not operate properly in a windows file system, it just that simple!
Post by Andrew AlexanderOne big advantage is that every month you can put the system down and
close the emulator and ZIP up the drive files 100MB each with mostly
blank space will compress into like 6 or 7MB... it makes things so easy.
I have several back ups of my system over the last couple years in hard
drive files.
Post by d***@propg.comActually the emulator does not cause this error at all. If you were to
install this on an actual Amiga you would be having the same
problem.
Post by Andrew AlexanderPost by d***@propg.comPlus your solution will only solve the issue until Tom changes his
access level.
The problem is not in my book of notes so I assumed it never happen to
me on the real Amiga. A lot of people don't realize that my BBS didn't
start on the emulator... it was run for a couple years and compressed
and stored on CD up until 2002 when I opened the BBS back up. I think
this advantage is why I don't have many of the problems people report
with systems. I was the first to sustain a CNet BBS in WinUAE and I was
the first to move that same system to the Amiga One. =)
I am not sure why it never happened to you as I have tested on an Amiga
2000, 3000, & 4000 and WinUAE and got the same results. Mabey your
5.01 install package does not have this problem and thats how you
avoided it. Not sure.
I have to correct myself as I incorrrectly identified the source of the
problem as the VDE files. While these files do no get create properly
in the install they are not the source of THIS issue. I knew the
problem was with the default access group settings, but for some reason
I jumped to the VDE files as the place. This morning it hit me that's
not the location of the access group settings. Sorry, I guess I was
rather tired when I posted it.
In any case the problem comes from the fact the default values in the
access group file "sysdata:bbs.adata" for all access groups have the
accounts suspended. So when the system has no users and the sysop hits
the tab key it will create the first account and apply access group 0's
setting to it. Because access group 0 has the suspended account flag
set, the account now suspended. Rather then fix the real issues here
the newer version 5.07 does not kick off the user if they are in local
mode and so you can just edit the account. Don't forget to edit the
groups either.
Post by Andrew AlexanderPost by d***@propg.comThe error comes from an incorrectly programmed install utility that is
used to create the VDE files. During the install, a utility is run to
generate a set of VDE files. These files are used in the VDE (Visual
Data Editor). Here is where the problem lies. The utility creates the
VDE files, and sets all the defaults for each of the files. One of the
VDE files is for the Access Groups. In this file, the suspend account
flag is set to true in all access groups. So when you hit TAB for the
first time on the system, it sees there is no accounts yet and creates
the first account. Because all accounts have to be set at some access
level it sets the access level to 0 (I think) and then applies all the
appropriate access level settings for group 0 to the account. This is
why, when you change your access to level 31, your account will get
suspended again. So to counter this, get on the system using the
method Andrew identified and then issue the following command "EG0-31".
This will get you into the VDE editing all groups. Then turn off the
suspended flags and I seem to think there is another that needs to be
changed, but you should see what we are trying to do.
There are some other errors in the VDE files that are more cosmetic
(like one of the fields did not line up right, etc...), but I did not
want to leave them so I adjusted mine to suite me.
Wow... ok... I got tired of getting my ass kicked by Red Hat Linux over
here tonight and I messed with this. My solution does not correct the
problem... However, I have a 5.01 (my orignal version) that I do most of
the tests on in the emulator. My current system runs 5.06 (Phear to do
the Upgrade). So if his install is 5.07 it may work it may not. I recall
someone else did that method and it worked, so I don't know... just
gonna have to wait and find out.
In my tests tonight nothing I did allowed me to get into the BBS which I
don't ever recall that happening when I started with 5.01 before on a
real Amiga. I guess it's possible though. Quite a disturbing turn of
events hey? A syspended sysop...
I can work with you to try and get you into the system using your
current version of 5.01. You just need a few files from me that will
get you up and running. However, like Andrew stated you should scrap
the 5.01 and use a 5.07 install package. Let me know if you need it.
Just be sure to copy your bbslicense file into the new install package
before installing it. Plus if you are going to use a 5.07 install,
don't install overtop of the old version. That will create a whole new
set of issues to deal with. It's best to clear out your system of CNet
all together and then start from scratch. If you need instruction on
how to get this done, let me know and I will send you some.
D5