Date: Wed, 12 Jan 2005 12:31:18 +0100 From: Philip Nienhuis <[EMAIL PROTECTED]> Subject: Re: [LIB] When EZ-Drive is a >must< for W98 * W2K installations
Matt Hanson wrote: > > Date: Wed, 12 Jan 2005 00:03:15 -0800 (PST) > From: Matt Hanson <[EMAIL PROTECTED]> > Subject: Re: [LIB] When EZ-Drive is a >must< for W98 * W2K installations > > From: Philip Nienhuis <[EMAIL PROTECTED]> > ...<snip> > > Something I noted when doing a more time consuming binary comparison of a > few MP3 files a while back with BC, is that one particular program > character, a 'y' with an umlout above it was replaced with an 'i' character > with an umlout when the files were copied over. But it doesn't seem it'd > be an issue here, would it? I wouldn't know, though I'd search that option too. XP & Win2K are based on Unicode (double byte char set), Win9x is AFAIK not. But AFAIK the file systems should be transparent to both Windows versions. You probably copied the files in Explorer, no? You can also copy them in a DOS prompt / command window using something like XCOPY /S /D /E /C /H /V or so (type XCOPY /? for usage options). Especially /V is useful as it verifies each copied file. >From your last post I understood that you used Win2K to copy the files over the LAN. What would happen if you use W98? > > A suggestion: > >- Perhaps your G:-partition has bad blocks? ...<snipped conclusion = no bad blocks?> ...<snip> > >> At that point I gave up... installed EZ-Drive again... ran Scandisk from > >> W98, and it found no errors at all. > > > Because EZ-drive shifts all tracks one up (to hide itself), > > It seems there's got to be more to it than that Philip. W2K seems to have > a much more broad 'understanding' of how partitions and file systems work > than W98SE does. Oh yes I fully agree here. Compared to Win2K, Win9x is just a collection of hacks, kludges and trickery. But normally it is quite reliable. Zillions of people stil run W9x w/o problems. But what I meant is that shifting a partition one cylinder or track up may help to avoid bad blocks an/or previous data. Bad blocks is no black & white thingy, it is a sort of gradual decline of disk surface detoriation that may or may not show depending on a *lot* of circumstances. OS #1 might note it, OS #2 not. OS #A may try 5 times and then give up, OS #B may try just twice. It depends.... Previous data may also clobber up FATS etc. I encountered situations more or less like yours which I simply did not trust. Just to be sure, I changed & shifted partition layout several times to avoid these situations. Although admittedly I am not sure what the cause was of my problems, it did help in my case. > It >ought< to for MSs sake. After all, W2K is smart > enough to create an 0c logical partition where it's needed. Whereas my Beware... Win98 or even DOS FDISK will do that too! but it needs a proper BIOS to do so, that means that it won't work in a Libretto. But on my desktop, which has a proper BIOS, it worked OK. > very 'MS Windows based' Partition Magic v8.0 doesn't want to do it. AAMOF > I found that by merely >running< PM 8.0 on this 40GB HDD in question and > not doing any modifications at all, it would auto-convert the 0c partition > I set with Ranish to a type 0b! And that no doubt reflected PoweQuest and > MS's viewpoint towards disk partitioning at some point in the near past > which has now changed. Yes that is a (severe) limitation of PM. I tend to dump programs that change things behind your back especially if they do so while you did not ask for any changes at all. Moreover, IIRC you ran PM in your desktop, didn't you? If it made 0B FAT32 logical partitions beyond 8 GB in your desktop, PM is simply buggy. ....<snip> > > >> Since MS-DOS wasn't able to see the G: drive from the DOS prompt with > the > >> area of the extended partition it was sitting on set to 0f, I put the > HDD > >> back in the desktop (actually >before< installing EZB) and reset it to > >> 05. > > > Did MS-DOS see it then? I wouldn't expect that, rather the other way > > round. > > With the extended partition area for G: set to 0F, no... MS-DOS failed to > see any logical G: drive at the DOS prompt. It could access logical D:, E: > and F: <8GB, but not G: >8GB. With it set to 05, I could access the G: > drive in DOS. That seems to be just the opposite of what you wrote below: > > "DOS can't see both FAT32 partitions unless I change the > extended partition type to 0F. > > Are we talking about the same extended partition components? The first No, read on..... > entry for an extended partition I see in Ranish is one that fills the > entire drive from just after the 1st primary to the end of the drive. My > setup has that set to 0F. Then for each segment of that extended That is the entire extended partition, yes. For DOS that needs to be 0F. For Windows (Win9x once it has booted out of DOS) it can be either 0F or 05. > partition, there are individual extended segments that are set to 05: > > C: Primary type 0B > Extended type 0F <Area from end of C: to end of drive > D: Logical type 0B > Extended type 05 <Area of extended partition D: sits on > E: Logical type 0B > Extended type 05 <Area of extended partition E: sits on > F: Logical type 0B > Extended type 05 <Area of extended partition F: sits on > G: Logical type 0B Hmmm..... not type 0C? > Extended type 05 <Area of extended partition G: sits on > > When I switch the portion of the extended partition G: sits on from 05 to > 0F, MS-DOS can no longer see the drive. Are you seeing the opposite? Or > are you switching the type 0F to 05 in the entry for the full extended > partition that spans all logical drives? For DOS it should be set to 0F in what you call "the container", that is the entry for the entire extended partiton in the (main) MBR which is on cyl. 0 head 0. Try to change it to 05 there and then you'll see DOS won't see anything beyond 8 GB, although FDISK will still see that the extended partition itself is much bigger (don't use FDISK to change it!). FDISK just echoes the MBR entries the way it finds them. What you mentioned above (and something which never occurred to me) is that you can also change the partition type in the EMBRs; those EMBRs are a linked chain of MBR's that point to the logical partitions and the next EMBR. I've never fiddled with those EMBR partition types. So probably they are set to 05 in my case, too. In conclusion, you and I clearly talked about different things. I referred to the entire-extended-partition entries in the MBR, you referred to the EMBRs. > > Look, I've got no EZ-drive or similar disk manager on a 60 GB hard > > drive; beyond 8 GB are two FAT32 partitions of 10 GB/25,000+ files > > and 15 GB / 30,000+ files. Never had any problems with those. > > My extended partition = type 05, both FAT32 partitions are 0C. > > Well... something's going on we haven't put our fingers on. It may have > something to do with the character of my backed up data. > > > DOS can't see both FAT32 partitions unless I change the extended > > partition type to 0F. 0F or 05 doesn't make any difference to Windows > > (all versions) but the in case of 0F OS/2 Warp can't see the extended > > partition. > > I'm still not grasping what you're saying there. If Windows can't see your > FAT32 partitions without setting the extended partition to 0F, it sounds > like it >does< make a difference to Windows. No it makes a difference for DOS, not for Windows. Once Windows (any version > Win95 OSR-B) has booted, it can access either 05 or 0F extended partitions (the "container"). But early in booting stage Win9x is still DOS, at that time it can't find logical partitions > 8 GB if the extended partition is 05 type. (OS/2 simply needs the ext. partition "container" to be 05 type.) Still your scandisk problems are a mystery. Especially because W2K has no problems at all and W98 chokes on it. That is fascinating to say the least... P.
