Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!uunet!seismo!gatech!bloom-beacon!husc6!cmcl2!beta!hc!ames!oliveb!dragon From: dragon@oliveb.UUCP (Give me a quarter or I'll touch you) Newsgroups: comp.sys.atari.st Subject: Re: DCFORMAT not quite right... Message-ID: <2010@oliveb.UUCP> Date: Mon, 13-Jul-87 11:59:36 EDT Article-I.D.: oliveb.2010 Posted: Mon Jul 13 11:59:36 1987 Date-Received: Tue, 14-Jul-87 05:48:00 EDT References: <1417@bath63.ux63.bath.ac.uk> Distribution: world Organization: Dragon Technology, Inc. San Francisco, USA Lines: 30 in article <1417@bath63.ux63.bath.ac.uk>, pes@ux63.bath.ac.uk (Smee) says: > Carrying on with my experiments with swapping 3.5 inch disks between the ST and > an IBM clone, I tried using DCFORMAT's 'put on a MS/DOS header block' feature. > (The disk had been formatted 'normally' (DS, 80 trk, 9 sect) using DCFORMAT. > Our PC (using DOS 3.2) was not at all happy with it. Was a bit funny, though. > The files (put on on the ST) 'listed' correctly. DOS had no problems with > the directory (root). Files less than one cluster long read correctly. > However, files > one cluster were painfully garbaged. So, something goes > wrong when the IBM has to look at the FAT. (For short files, it doesn't have > to check the FAT to determine end of file, because of course the length is > contained in the directory entry.) When I modified the boot sector of an ST disk, as instructed a while back (using Norton's 4.0 on a PS/2 Model 50 running PC-DOC 3.30), the PC could dir the disk fine, but any files we tried to copy off would be truncated. Could this be related in any way? I was hoping to not have to copy 30 disks to IBM format to get them on a BBS run on an IBM... it would take weeks! -- Dean Brunette {ucbvax,etc.}!hplabs!oliveb!olivej!dragon Olivetti Advanced Technology Center _____ _____ __|__ _____ 20300 Stevens Creek Blvd. | | _____| | | Cupertino, CA 95014 |_____| |_____| |__ |_____