jdh@bsu-cs.UUCP (John Hiday) (01/23/89)
I think I have discovered a bug in the write-locking of an FFS partition.
I have tried to send a notice to bugs@cbmvax, but I haven't gotten a reply
back so I am assuming that nothing made it through.
It seems that LOCKing an FFS partition does not prohibit a program from
writing to an existing file (appending or overwriting). I have reproduced
this on both my hard drive and RAD: (the only FFS devices I have). I
had a friend try it out too and he came up with the same results.
The Info command shows the partition as Read Only, and any attempt to
create a new file or delete an old one is met with the "Volume xyz is
write protected" requester. However appending to and/or overwriting an
existing file succeeds.
A simple way to demonstrate this is to add a comment to an existing
Zoo archive which is on a LOCKed partition (zoo cA archivename).
Creating a new archive will fail, but adding to an old one succeeds.
I realize that the only "real" write-protection comes from hardware, but
I was expecting a little more than this from LOCK.
Is this a bug or am I missing something?
--
UUCP : <backbones>!{iuvax,pur-ee,uunet}!bsu-cs!jdh John Hiday
BITNET: 00JDHIDAY@BSUVAX1.BITNET Ball State Univ Computing Services
GEnie : JDHIDAY Muncie, IN 47306jesup@cbmvax.UUCP (Randell Jesup) (01/23/89)
In article <5411@bsu-cs.UUCP> jdh@bsu-cs.UUCP (John Hiday) writes: >I have tried to send a notice to bugs@cbmvax, but I haven't gotten a reply >back so I am assuming that nothing made it through. Not necessarily a good assumption. I don't think that we (at current) respond unless the person dealing with the subsystem decides he needs more information. We just switched bug-handling people so this may be up in the air at present. -- Randell Jesup, Commodore Engineering {uunet|rutgers|allegra}!cbmvax!jesup
sneakers@heimat.UUCP (Dan "Sneakers" Schein) (01/24/89)
In Message <5411@bsu-cs.UUCP>, jdh@bsu-cs.UUCP (John Hiday) writes: >I think I have discovered a bug in the write-locking of an FFS partition. >I have tried to send a notice to bugs@cbmvax, but I haven't gotten a reply >back so I am assuming that nothing made it through. > Thats not a good assumption. The person doing bugs may be busy, may have not checked the mail yet, or may be trying to reproduce it. >It seems that LOCKing an FFS partition does not prohibit a program from >writing to an existing file (appending or overwriting). I have reproduced >this on both my hard drive and RAD: (the only FFS devices I have). I >had a friend try it out too and he came up with the same results. The lock on my hard drive wont let me update or append a file (existing or not) using standard DOS commands. >The Info command shows the partition as Read Only, and any attempt to >create a new file or delete an old one is met with the "Volume xyz is >write protected" requester. However appending to and/or overwriting an >existing file succeeds. See above. >A simple way to demonstrate this is to add a comment to an existing >Zoo archive which is on a LOCKed partition (zoo cA archivename). >Creating a new archive will fail, but adding to an old one succeeds. I tried this and your right! Zoo does change the file (as indicated by the date stamp). But I havent been able to get anyting else (besides zoo) to reproduce this. Darn this shoots my theory of keeping the Euro-Virus out of my C: directory. Sneakers -- Dan "Sneakers" Schein {pyramid|rutgers|uunet}!cbmvax!heimat!sneakers Sneakers Computing 2455 McKinley Ave. Of course heimat is an Amiga. West Lawn, PA 19609 Doesn't everyone run UUCP & UseNet on an Amiga? Call: BERKS AMIGA BBS - 60+ Megs - 24 Hrs - 12/2400 Baud - 215/678-7691
cg@myrias.UUCP (Chris Gray) (01/25/89)
In article <6028.AA6028@heimat> sneakers@heimat.UUCP (Dan "Sneakers" Schein) writes: >In Message <5411@bsu-cs.UUCP>, jdh@bsu-cs.UUCP (John Hiday) writes: >>I think I have discovered a bug in the write-locking of an FFS partition. >>A simple way to demonstrate this is to add a comment to an existing >>Zoo archive which is on a LOCKed partition (zoo cA archivename). >>Creating a new archive will fail, but adding to an old one succeeds. > I tried this and your right! Zoo does change the file (as indicated by the > date stamp). But I havent been able to get anyting else (besides zoo) to > reproduce this. Um, could this be that the files are being opened with different access modes (MODE_WRITE, MODE_READ, or whatever they are)? I seem to recall that you can write to a FileHandle that you've supposedly opened read-only. Oh dear, now I have to type in some more stuff so that 'postnews' won't reject my article. I wonder if I will have this problem running Dan's UUCP when my new hard disk arrives? Well, I guess I'll just have to wait and see, won't I. Maybe if I go back and delete some empty lines.... -- Chris Gray Myrias Research, Edmonton +1 403 428 1616 {uunet!mnetor,ubc-vision,watmath,vax135}!alberta!myrias!cg
jdh@bsu-cs.UUCP (John Hiday) (01/25/89)
In article <6028.AA6028@heimat> sneakers@heimat.UUCP (Dan "Sneakers" Schein) writes: >In Message <5411@bsu-cs.UUCP>, I write: >> [assume no reply from bugs@cbmvax means that nothing made it through] > Thats not a good assumption. The person doing bugs may be busy, may have > not checked the mail yet, or may be trying to reproduce it. I guess I didn't say how long I waited before posting. The mail went out three weeks ago. > [...] > I tried this and your right! Zoo does change the file (as indicated by the > date stamp). But I havent been able to get anyting else (besides zoo) to > reproduce this. > > Darn this shoots my theory of keeping the Euro-Virus out of my C: > directory. The following program will also demonstrate this: #include "stdio.h" main() { FILE *output; if (output = fopen("xyz","a")) { /* To overwrite add an fseek() here */ fprintf(output,"This line was appended\n"); fclose(output); } else { printf ("Can't open file\n"); } } I used Manx 3.6a, but Lattice should work too. To use it create a garbage file named "xyz" (like Dir >xyz), LOCK the partition containing "xyz", execute the program and look for the message at the end of the file. The Dillon/Drew shell (version 2.07m at least) exhibits the problem when using >> to redirect output. That's how I originally discovered it. -- UUCP : <backbones>!{iuvax,pur-ee}!bsu-cs!jdh John Hiday BITNET: 00JDHIDAY@BSUVAX1.BITNET Ball State Univ Computing Services GEnie : JDHIDAY Muncie, IN 47306