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...

[Vanilla]

Check the protection bits in WB Info and make sure RWD is set for read/write/delete. Also check it's parent dir for the same thing.

The only time I come across this kind o fthing is when I have a file open in an editor and try to use it elsewhere.

[Thomas]

Save the file as startup-sequence.new then open a Shell window and enter

cd s:
rename startup-sequence startup-sequence.old
rename startup-sequence.new startup-sequence

If you get error messages, don't keep them secret. We aren't able to see them in our cristal balls and we cannot help you if we don't know them.

[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)

[Thomas]

User-Startup is write protected. Enter

protect s:user-startup +wd

to unlock it.

[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.

[paul1981]

Are you using a real Amiga here or UAE?

[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!

[zipper]

I have faint memory that some nasty virus screwed protection bits on my HD long time ago - had to run protect for everything.

[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...

[paul1981]

I don't know anything at all about MUFS, but you say that you changed DH0: to FFS, so I'm assuming you're using DH1: still with MUFS?
If MUFS is on the RDB (if that's how it works) then it is still active I believe, so could well be causing you trouble....

Like Zipper said, it's worth doing a Virus scan. I recommend VirusZ.

Also, this could be file system corruption I suppose.
In that case, drag your DH0: somewhere onto your DH1: to back it up, and then reformat DH0: and copy everything back again. Of course this would be the last resort.

To check that you are actually using FFS on DH0: just type in "version dh0:" at a shell, and it will tell you the filesystem in use.

[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....