mjf@cunixb.cc.columbia.edu (Michael J Flory) (05/29/91)
Some time ago I posted with a strange and dangerous error I got running DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get it. In short, the diskcopy operation miscopied a couple of sectors every dozen-and-a-half or so (the number varied). But although VERIFY was on, I got no error message -- I discovered it through DISKCOMP. Now, running XTREE GOLD 2.0 under windows, I have discovered that the beginning parts of whole sets of files copied to a floppy are sometimes trashed, and (as I recall -- one of the files trashed was my notes on the other problem) these file-beginnings were trashed in the same way: every OTHER byte became FF, beginning with the 2nd byte. The number of bytes varied, but seemed always to end on a sector boundary. It reminded me of the way the version of DOS installed by OEM's when you don't buy a full DOS would copy itself to a floppy -- every other byte zeroed! I've tested the RAM in my machine, and my floppy drive seems reliable (other files read and write fine). Could Windows be misallocating memory for DOS (3.30, by the way) and allowing something else to write over it? Any help much appreciated. I'm mystified. Michael Flory (mjf@cunixb.cc.columbia.edu)
colfelt@news.colorado.edu (COLFELT ANDREW BRINTON W) (05/29/91)
mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: >Some time ago I posted with a strange and dangerous error I got running >DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get >it. In short, the diskcopy operation miscopied a couple of sectors every >dozen-and-a-half or so (the number varied). But although VERIFY was on, >I got no error message -- I discovered it through DISKCOMP. The best way to avoid this would be to run the DOS window full-screen. It sounds a little like the floppy errors could be caused by the switching of CPU attention. When you're 'multitasking' in Windows and performing a sensitive operation like copying sector-for-sector, the time-lag, skip, stutter, whatever, the window is causing a lack of proper 'attention' to the process and thus bytes are getting dropped. Try DISKCOPY in DOS, full-screen, and see if the problem goes away. Better yet, try the window again, with the BackGround Box checked. If the disks still lose bytes, try full-screen, BackGround. One of these setups should allow the CPU to devote sufficient attention to the copying process to maintain good housekeeping on all bytes in all sectors. (I presume you're running a 386, since you'd not have the windowed DOS option with a 286.) -- ______________________________________________________________________________ Andrew BW Colfelt colfelt@tramp.colorado.edu____________________________________________________ -- ______________________________________________________________________________ Andrew BW Colfelt colfelt@tramp.colorado.edu____________________________________________________
mjf@cunixb.cc.columbia.edu (Michael J Flory) (05/29/91)
Andrew Colfelt kindly replied to my query about errors copying disks in Win3: >mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: >>Some time ago I posted with a strange and dangerous error I got running >>DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get >>it. In short, the diskcopy operation miscopied a couple of sectors every >>dozen-and-a-half or so (the number varied). But although VERIFY was on, >>I got no error message -- I discovered it through DISKCOMP. >The best way to avoid this would be to run the DOS window full-screen. It >sounds a little like the floppy errors could be caused by the switching of >CPU attention. When you're 'multitasking' in Windows and performing a >sensitive operation like copying sector-for-sector, the time-lag, skip, >stutter, whatever, the window is causing a lack of proper 'attention' to the >process and thus bytes are getting dropped. >Try DISKCOPY in DOS, full-screen, and see if the problem goes away. Better >yet, try the window again, with the BackGround Box checked. If the disks >still lose bytes, try full-screen, BackGround. One of these setups should >allow the CPU to devote sufficient attention to the copying process to >maintain good housekeeping on all bytes in all sectors. Thanks very much for the advice. When I read it I realized, though, that I hadn't explained myself too clearly. I carelessly interchange "in a window" and "in a windows session" and I did it here -- I *think* I ran things in full-screen when I got the errors. I usually do just 'cause it's faster. But I am going to experiment a little and see if I can duplicate the error in a window and out. Also, I always check the "background" box when I run things in the background -- as I usually run them full-screen. The thing that struck me about the errors was their regularity. In the DISKCOPY problem, I got messed-up cylinders at regular intervals: for example, cylinders 4, 5, 28, 29, 52, 53, ... might be bad (I'm making the numbers up, and the intervals and exact values varied, but the patterning was of that sort consistently). In the (related?) problem copying files under XTREE GOLD 2.0, the *beginnings* of the files were bad (it never started in the middle of a file) and every other byte was wiped out, ending on a nice even offset (e.g. 10000 hex). That's why I started by looking for a bad RAM chip. I'll experiment a little more and follow up. If Windows is allowing an application to access more memory than it is really protecting, this could be something nasty. Oh -- yes, I am running a '386DX in Enhanced Mode. I use Fastopen, Smartdrive, Himem, and Ramdrive in 4 megs of RAM, and aside from too many device drivers I don't think there's anything exceptional about my setup. Again, thanks very much for the help! Michael Flory (mjf@cunixb.cc.columbia.edu)
stevens@shiva.trl.OZ.AU (Tony Stevens) (05/29/91)
mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: I have had similar experiences with Windows copying what appeared to be junk to a floppy drive - 1.2Mbyte, 360kbyte, 5 1/4 or 1.4Mbyte 3 1/2. >Some time ago I posted with a strange and dangerous error I got running >DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get >it. In short, the diskcopy operation miscopied a couple of sectors every >dozen-and-a-half or so (the number varied). But although VERIFY was on, >I got no error message -- I discovered it through DISKCOMP. In my case the errors in a dos window occur when I run a batch file containing a XCOPY or COPY statement, and produce FF hexidecimal for every forth byte of the file. >Now, running XTREE GOLD 2.0 under windows, I have discovered that the >beginning parts of whole sets of files copied to a floppy are sometimes some deleted The problem was first noticed using XTREE GOLD 1.3 (I think this is the version). One of my solutions was to set the following in the SYSTEM.INI file in the [386Enh] section: EMMExclude=A000-DFFF required because of Paradise VGA Driver 256 colors. VirtualHLRD=off suggested somewhere ?? if you have drive problems. These fixed my problems both with XTGOLD and dos window in most cases. The problem still occurs sometimes if I try doing an add or update operation to ZIP file on the floppy drive or if the file being copied is very large 800kbytes. The above may help you. If you get any replies I also would be interested. The batch file mentioned above is for backups of the hard drive and the files are not much good if the 4th byte is FF hex. A.J. Stevens (Tony) || Internet: a.stevens@trl.oz.au Manager Plans & Programmes || Tel: +61 3 5416532 Telecom Research Laboratories, PO Box 249, CLAYTON VIC 3168, AUSTRALIA **** Jesus is Lord ****
rb9a@kelvin.seas.Virginia.EDU (Raul Baragiola) (05/29/91)
In article <1991May29.065802.22317@trl.oz.au> stevens@shiva.trl.OZ.AU (Tony Stevens) writes: >mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: > >I have had similar experiences with Windows copying what appeared to be >junk to a floppy drive - 1.2Mbyte, 360kbyte, 5 1/4 or 1.4Mbyte 3 1/2. > >>Some time ago I posted with a strange and dangerous error I got running >>DISKCOPY in a DOS window with a .pif asking for all 640 K if it could get >>it. In short, the diskcopy operation miscopied a couple of sectors every >>dozen-and-a-half or so (the number varied). But although VERIFY was on, >>I got no error message -- I discovered it through DISKCOMP. > >In my case the errors in a dos window occur when I run a batch file >containing a XCOPY or COPY statement, and produce FF hexidecimal for >every forth byte of the file. > >>Now, running XTREE GOLD 2.0 under windows, I have discovered that the >>beginning parts of whole sets of files copied to a floppy are sometimes > > some deleted > >The problem was first noticed using XTREE GOLD 1.3 (I think this is the >version). > >One of my solutions was to set the following in the SYSTEM.INI file in >the [386Enh] section: > > EMMExclude=A000-DFFF required because of Paradise VGA Driver 256 > colors. > VirtualHLRD=off suggested somewhere ?? if you have drive > problems. > >These fixed my problems both with XTGOLD and dos window in most cases. > >The problem still occurs sometimes if I try doing an add or update >operation to ZIP file on the floppy drive or if the file being copied is >very large 800kbytes. > I have the same problems writing to floppies. I feel that it is more likely to occur with large files just because more bytes are written. I will also like to know why this happens and how to fix it. -- Raul A. Baragiola \Internet: raul@virginia.edu Dept. Nuclear Engnr. and Engnr. Physics \Phone: (804)-982-2907 University of Virginia, Charlottesville, VA 22901 \ Fax: (804)-924-6270
press@venice.SEDD.TRW.COM (Barry Press) (05/30/91)
In article <1991May29.065802.22317@trl.oz.au> stevens@shiva.trl.OZ.AU (Tony Stevens) writes: >mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: > ..... <Stuff deleted> ..... > >One of my solutions was to set the following in the SYSTEM.INI file in >the [386Enh] section: > > VirtualHLRD=off suggested somewhere ?? if you have drive > problems. Are you sure you got this one right? I could believe this line: VirtualHDIRQ=off (or false or 0) but the one you gave is completely new to me. Presumably Windows ignores settings it doesn't recognize, so it may be that you mis-spelled it and the other things you did fixed your problem. On the other hand, if this really is a valid setting, could you post the description of what it does? -- Barry Press Internet: press@venice.sedd.trw.com
mjf@cunixb.cc.columbia.edu (Michael J Flory) (05/30/91)
More on the bad behavior of Windows in writing to floppies...
I just read Raul Baragiola's post saying he'd had problems similar to mine
writing to floppies in a DOS session under windows, and I'm putting that
together with Tony Stevens' comments on how excluding his video memory helped.
As I mentioned, my notes on the first problem (DISKCOPY in a DOS session)
were trashed by the second problem (XTREE GOLD 2.0 wrote my notes to a floppy
with many sectors missing every other byte)! But I now recall that a sort
of fix was to either reduce the size of the memory my COMMAND.PIF asked for
(I made my own to get around the small amount of memory the DOS icon in
the Main folder gives me, and asked for all 640K if available) OR to reduce
the amount of memory allocated to Windows by specifying a value under 640K
for the winmemsize variable in the [win386] section of WIN.INI. There seemed
to be a maximum allowable COMBINED size for the two -- in my case, about 1Meg.
This seemed to prevent the bad DISKCOPY's in my DOS session.
At this juncture, my suspicions are narrowing as follows:
My floppy drive behaves perfectly otherwise, so I rule it out.
My RAM passes both the POST and a diagnostic RAM test, so it seems OK.
(If I were using memory interleaving I would be more suspicious of the RAM,
as that could explain the every-other-byte-bad pattern.)
I think the problem occurred in full-screen DOS sessions as well as in a
window, so I don't *think* that what Andrew Colfelt suggested -- that I
might be losing time-slices in a windowed session -- is the answer. (A
consultant at Columbia's computer center, TJ Lee, also suspected a timing
problem, with another application stealing slices at the wrong time, but
I think the problem is too *regular* -- in DISKCOPY, the pattern of trashed
sectors was two sectors every X sectors, probably implying two bad sector
copies every disk swap.)
I'm using only a 256K video adapter (tho' it is superVGA capable -- Video7
1024) and I'm in 16-color mode, so I don't *think* that's it.
It looks like Windows is misallocating memory to DOS tasks, then, giving
the sessions more memory than it is really protecting. I don't understand
the intimacies of memory protection in the 80386's virtual 8086 mode, but
it looks like Windows is possibly writing over some of the memory itself,
as it, at least, is always active (with the DISKCOPY problem, at least, not
much else was going on when it screwed up). This occurred only in DOS
sessions begun with a .pif file; oddly, though I listed a .bat file in my
run line in WIN.INI, Windows ran my .pif file for Windows anyway. This .pif,
like the one for the command line, asked for 640K if it could get it. I
recall trying all sorts of other combinations in the "advanced" section of
the PIF editor to no avail.
After the DISKCOPY problem showed up I looked into alternatives to DISKCOPY.
But with the XTGOLD problem and other suspicious behavior (DOS session apps
getting at other DOS apps' memory, etc.) I am going to reduce my winmemsize
to 448K (as I recall that didn't slow things too badly, surprisingly) and
see if I can avoid asking for more than 512K in .pif, less if possible.
(That'll spare me a little swapping, too, I hope!) Meanwhile, I'm looking
into OS/2 2.0 -- sounds like even the beta might give better virtual process
protection.
Thanks to all who have helped me with this mess -- and by saying that I don't
mean to cut the discussion thread short here, any more ideas or experiences
would certainly interest me. One final note: I learned the hard way that
VERIFY ON apparently doesn't affect disk writes under anything but COPY!
_____________________________________________________________________
Michael Flory (mjf@cunixb.cc.columbia.edu)
"Yes, the computer did arrive "just in time." But in time for what?"
-- Joseph Weizenbaum, Computer Power and Human Reason
_____________________________________________________________________mjf@cunixb.cc.columbia.edu (Michael J Flory) (05/30/91)
Reread my posting as it came through. I meant to say that Windows used my .pif for XTGOLD, even though I listed only my XTGOLD.BAT file on the run line in my WIN.INI. This was re: the fact that the bad disk-file copies seemed to happen in DOS sessions where a .pif had asked for 640K, or even less if winmemsize was big. Michael Flory (mjf@cunixb.cc.columbia.edu)
press@venice.SEDD.TRW.COM (Barry Press) (05/30/91)
In article <1991May29.175240.14589@cunixf.cc.columbia.edu> mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: > >More on the bad behavior of Windows in writing to floppies... > > ... A lot of notes deleted ... > >I think the problem occurred in full-screen DOS sessions as well as in a >window, so I don't *think* that what Andrew Colfelt suggested -- that I >might be losing time-slices in a windowed session -- is the answer. (A I'm not convinced that the complete point of the fix he suggested got across. In particular, running full screen DOES NOT by itself ensure that your process does not get interrupted. I can verify this by noting that a clock (a WinApp) I use that beeps on the hour still beeps when I have a full-screen DOS session going. The other point he mentioned was to turn on EXCLUSIVE, either in the pif or in the settings (Alt-space, settings, etc.). While I haven't tested that, nor have I recently RTFM'd on it, I believe that it's purpose is to restrict the scheduler as he mentioned. Having played with pre-emptive schedulers (which is what you have relative to a DOS session, as opposed to within WinApps), I could believe that the behavior you see when you cut down the memory is due to changes in the timing of when the scheduler hits you. It's at least worth trying ... -- Barry Press Internet: press@venice.sedd.trw.com
rb9a@kelvin.seas.Virginia.EDU (Raul Baragiola) (05/30/91)
In article <1991May29.175240.14589@cunixf.cc.columbia.edu> mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: > >More on the bad behavior of Windows in writing to floppies... > .................................................. >would certainly interest me. One final note: I learned the hard way that >VERIFY ON apparently doesn't affect disk writes under anything but COPY! >_____________________________________________________________________ Well, I got this peculiar tipe of error using xcopy with the /v option and VERIFY ON. -- Raul A. Baragiola \Internet: raul@virginia.edu Dept. Nuclear Engnr. and Engnr. Physics \Phone: (804)-982-2907 University of Virginia, Charlottesville, VA 22901 \ Fax: (804)-924-6270
stevens@shiva.trl.OZ.AU (Tony Stevens) (05/30/91)
press@venice.SEDD.TRW.COM (Barry Press) writes: >In article <1991May29.065802.22317@trl.oz.au> stevens@shiva.trl.OZ.AU (Tony Stevens) writes: >>mjf@cunixb.cc.columbia.edu (Michael J Flory) writes: >> ..... <Stuff deleted> ..... >> >>One of my solutions was to set the following in the SYSTEM.INI file in >Are you sure you got this one right? I could believe this line: > VirtualHDIRQ=off (or false or 0) You are correct, I typed it from memory as it was on my home machine. Just a though my home machine has AMI BIOS while my work machine, which does not indicate the problem has Phoenix BIOS. A.J. Stevens (Tony) || Internet: a.stevens@trl.oz.au Manager Plans & Programmes || Tel: +61 3 5416532 Telecom Research Laboratories, PO Box 249, CLAYTON VIC 3168, AUSTRALIA **** Jesus is Lord ****
mjf@cunixb.cc.columbia.edu (Michael J Flory) (05/30/91)
Barry Press (press@venice.sedd.trw.com) suggested in reply to my reply to Andrew Colfelt's suggestion re: DOS apps in Windows writing bad sectors to floppies, >>I think the problem occurred in full-screen DOS sessions as well as in a >>window, so I don't *think* that what Andrew Colfelt suggested -- that I >>might be losing time-slices in a windowed session -- is the answer. >I'm not convinced that the complete point of the fix he suggested got >across. >In particular, running full screen DOES NOT by itself ensure that your >process does not get interrupted. I can verify this by noting that a >clock (a WinApp) I use that beeps on the hour still beeps when I have a >full-screen DOS session going. >The other point he mentioned was to turn on EXCLUSIVE, either in the pif >or in the settings (Alt-space, settings, etc.). While I haven't tested >that, nor have I recently RTFM'd on it, I believe that it's purpose is >to restrict the scheduler as he mentioned. Thanks for the advice -- maybe I'm too wedded to my idea that this is just a case of memory misallocation. You're right, I never did run my DOS apps in exclusive mode, and a lot of folk have suggested I should look at timing/bitslicing problems. I did a little more experimenting and now, of course, I can't replicate the problem! (It was appearing quite predictably -- the DISKCOPY problem, that is -- before...) One of the more DOSwise gurus on campus told me in no uncertain terms to get FASTOPEN out of my Windows setup, too. When I have some real time to put into this I will try to replicate the problems I was having with DISKCOPY and make experimental changes to the timesharing just to see what happens and I'll report. There are just so many variables in the system... I did try MANY changes to my setup when the problem first appeared, and only the adjustment of the .pif and winmemsize values seemed to help, but I wasn't thinking in terms of the timesharing... Meanwhile, I'm on the waiting list for the OS/2 2.0 "Early Experience Program." :) Michael Flory (mjf@cunixb.cc.columbia.edu)