SQ79%liverpool.ac.uk@nsfnet-relay.ac.uk (Mark Powell) (09/04/89)
Tos has worked fine and been a VVVVEEEERRRRRYYYY useful utility for reading/writing to floppy... however, it doesn't seem to work to harddisk. I tossed (hmmm) a tar file to one of my TOS partitions from minix and tried to untar it with a TOS tar utility... it didn't work. So, I immediately suspected the minix tos utility to be the culprit. I then tossed (that's why it's called tos??) a 5800 byte text file from minix to a TOS partition. From the desktop I could see that the file had been transferred with the correct length, however after an inspection with a sector editor I found that only the first 1K of text was present in the file and that the remaining ~5K was just junk. I checked the FAT tables to see it tos was corrupting them, but they were okay... 6 clusters allocated, all correctly linking, with an end marker. SO,... from all of this it must be that tos is preforming correctly, but losing it's pointer (or whatever) to the data that it is writing to the TOS partition after the first cluster is transferred. Right... that's the theory... has anyone else experienced this problem and if so how did they fix it???? Mark Powell ARPAnet : sq79%liv.ac.uk@nsfnet-relay.ac.uk USENET : ...!mcvax!ukc!liv.ac.uk!sq79
hcj@lzaz.ATT.COM (HC Johnson) (09/05/89)
In article <23191@louie.udel.EDU>, SQ79%liverpool.ac.uk@nsfnet-relay.ac.uk (Mark Powell) writes: > > Tos has worked fine and been a VVVVEEEERRRRRYYYY useful utility for > reading/writing to floppy... however, it doesn't seem to work to harddisk. ST TOS has several bugs, and limitations as written. The obvious ones: The size of the fat table can exceed 2^15 bytes. This shows up the face that sbrk(signed short) and read(signed short) screw up bad. LIBC isn't tuned for long integers. The location of the first data block under TOS is fixed by a formulat different than in the TOS program. This tends to ruin file systems fast. Some time past I posted a fix. If you cant get it locally, I send it. Howard C. Johnson ATT Bell Labs att!lzaz!hcj hcj@lzaz.att.com