Wierd Editing Bug

[Etherweet]

Has anyone else run accross a file getting changed so you can not overwrite it if you use cygnus editor or amiga ed? I'm just about ready to format and re install.  I haven't ruled out mufs from long ago, so i changed filesystems on dh0 to ffs.  i can not find a reason.  it definitely wont ever let me edit and save startup-sequence and user-startup.  i can write and edit and save source code from sas c all day long with no problems.  i used snoopdos and watched "lock" appearing as what looks like the os executing it.  i renamed lock and it still happens.  i made a simple script to make notes with and i can't edit it either.  it has only done this for a few weeks.  it didnt exist before that..ever...

[Etherweet]

first off THANKS for your help!!!

here is a dump of what i did:

13.WB_3.1:S> run ed Startup-Sequence
[CLI 6]

13.WB_3.1:S> list Startup-Sequence
Startup-Sequence            1712 ----rw-d Today     16:53:05
1 file - 5 blocks used

13.WB_3.1:S> rename Startup-Sequence Startup-Sequence.old

13.WB_3.1:S> list Startup-Sequence
No information for "Startup-Sequence": object not found

13.WB_3.1:S> list Startup-Sequence*
Startup-Sequence-NoWB       1480 ----rwed Sunday    00:26:36
Startup-Sequence.old        1712 ----rw-d Today     16:53:05
Startup-Sequence.new        1674 ----rw-d Friday    19:05:08
Startup-Sequence.Stock      1274 ----rwed Tuesday   23:45:31
Startup-Sequence.info        552 ----rw-d Friday    19:04:04
5 files - 21 blocks used

(i then saved startup-sequence from ed)

13.WB_3.1:S> list Startup-Sequence*
Startup-Sequence-NoWB       1480 ----rwed Sunday    00:26:36
Startup-Sequence.old        1712 ----rw-d Today     16:53:05
Startup-Sequence.new        1674 ----rw-d Friday    19:05:08
Startup-Sequence            1712 ----rw-d Today     16:54:29
Startup-Sequence.Stock      1274 ----rwed Tuesday   23:45:31
Startup-Sequence.info        552 ----rw-d Friday    19:04:04
6 files - 26 blocks used

(and just show whats b een done to user-startup as is)

13.WB_3.1:S> list User-Startup
User-Startup                2865 ----r--- Wednesday 22:55:13
1 file - 7 blocks used

13.WB_3.1:S>

(i hope i did what you wanted.. should have printed what you said to do)

[Etherweet]

hmmm

2 really weird things happened...........

thing 1:
so far i can edit and save startup-sequence ever since i did what you  said to do.

thing 2:
i didnt do anything with bits on user-startup to make it like it is currently.  i put it in ed and then deleted user-startup before trying to save it with ed and thats how it wound up on its own.

maybe a ray of understanding is beginning to set in for me.  could it be that ed and ced also, look at the bits when a file is opened and then try to lock the file while it is being edited so the protection bits sort of get registered screwed up and then the attempt to save the file is screwed up, preventing a write of the newly edited file (because the protection bits it used prevent it)..

sorta like screwed up protection bits in = even more screwed up protection bits out.

i think i might go ahead and do protect * +rwed (or protect #? +rwed) and see what happens.

[Etherweet]

a real 2000 with os 3.1 and the rom

i used to run multi user file system a while back and i thought maybe it was on the first rigid

disk block the system finds at boot and was screwing with protection bits.

i will try to do a tighter controlled experiment with a brand new file on different devices and so on and see if it is only going on in one place or everywhere, or wherever it just decides to do it.

i have even been thinking maybe the process of booting and running the startup and user startup files isnt actually finishing and closing them.

since you guys are so helpful i really need to make better notes (priding this bug lets me edit them)

thanks again!

[Etherweet]

ugh

looking through the list snoopdos generates, a lot of things are trying to "lock" a file, but the log says "failed'....

im going to use something like pagesetter on a test file in s: and see just what happens...

[Etherweet]

hey thanks for that little tidbit about version dh0:

i did watch closer using snoopdos and MAYBE.. i have useful info..

if i type ed anyfile, there is a copy of anyfile placed in dh0:T.

THEN

watching snoopdos (unknown application) tries to protect it and fails.

its morbidly fascinating to watch...  in the snoodos listing somethgni tries to put a copy in the following:

dh0:t
sys:t
t:

its almost a coin toss whether the unknown process succeeds or fails.

it is as though what really causes what APPEARS to me to be the problem is actually the failure to either protect, unprotect, overwrite whatever is REALLY going on in T: - where EVER it really is....

so now i have some stuff to help me try a better controlled test.

i will also do the format and re install thing - probably make it all academic..

again thanks a lot for all the help....