jaclaz

It must have happened many years ago or it was a really old drive. jaclaz

The patch: https://msfn.org/board/topic/178296-acpioff-pack-and-patch-for-win-9x-3x/ and a related thread with some install/use/troubleshooting tricks : https://msfn.org/board/topic/182563-win98-how-reboot-more-faster-and-turn-off-automatic/ jaclaz

Yes, I find probable that the Seagate controller Saxxon Saxon referenced has been artificially (and intentionally) limited by Seagate to their original (5 TB) hard disk. I am perplexed by the "third party" enclosures limitations, I could not find a valid reason (from specifications or math) why there should be a limitation at 4 or 5 TB (or at 8, etc.), nor I can imagine how the manufacturer would save even 0.01 $ on the BOM unless the actual chip(s) used come with different cpabilities at different prices (but then why would the chip manufacture produce several different models and I don't think that capacity can be the result of "lower quality" ascertained by post-production tests - like it was the case for the original 386's clock frequency) . About 5 TB disks being "decommissioned" 6 TB, It is entirely possible if - say - a 3 platters x 2TB hard disk has had a head (defective) disabled in firmware, but it is IMHO not probable for two reasons: 1) there are simply too many 5 TB disks around and at the time they came out there weren't 6 TB or they were very few 2) at least for the older hard disks the (few) cases I have had experience with the heads were disabled in pairs (i.e. both heads of a same platter) so to reduce a 6 TB to 5 TB it would have been a 6 platters by 1 TB each. Anyway the exact nature of the 5 TB disks is not at all relevant, the current mystery is about these limitations in the enclosure/converter hardware or firmware. jaclaz P.S. Addition/correction, after having had a quick look at this it seems like WD tends to keep 2 heads per platter (even), while Seagate seemingly uses "odd" ones, however I couldn't find and example of a 6 TB downsized to 5 TB, only of 3 and 4 TB disks made on the same "platform" maxing out at 5 TB: https://www.hddheadtools.com/st3000lm024-head-map-and-head-replacement-tool/

It doesn't seem to me a "strange" capacity AFAIK 5 TB is a "common enough" size, both in 3.5" and 2.5" form factor. jaclaz

Yep , OP (Cixert) knows very well how Seagate's enclosures may have issues: https://msfn.org/board/topic/183934-seagate-external-hard-drive-is-xp-incompatible/ but in your specific case that could be due to using a "proprietary" enclosure with another disk (i.e. the firmware of the Seagate enclosure might well have been "paired" to the original 5TB disk), the USB enclosures he is now using are "generic" and - at least in theory - should be compatible with *any* disk. And the even "stranger" thing is that - according to Cixert's experiences/reports - some limitations appear to be in the (new) firmware/hardware and not on older models from the same "generic" brand . I am calling the 5 TB as "strange" as it is not one of the more common (mathematical or from specifications) limits, the last one that I can remember is about the width of the emulated SCSI read and write commands in the USB layer, but that "jumps" from 32 bit (making the same 2.2 TB limit as other 32 bit related limits) to 64 bits, i.e. virtually unlimited: https://superuser.com/questions/308492/is-there-a-size-limit-on-external-usb-hard-drives This 5TB one seems more like an artificial cap (that could be explained on your Seagate enclosure) imposed by the "generic" manufacturer (or by the chip maker) for no apparent reason. Looking around on specs for USB external cases, I can find old ones with a 2 TB limit specified and some new ones with a (yet another) limit at 6 and another one at 8 TB (as well without AFAIK a math/spec reason for it), and even more setting the limit at 20 or 22 TB, most have no capacity limits explicited, . All in all it is a confusing mess. jaclaz

You could well have specified that, as is your post is incorrectly attributing me something I never said. BTW making a correct quote is possible, notwithstanding the (stupid) new iPB board software limitations: . jaclaz

It is entirely possible that your USB to SATA adapter(s) are translating sector size. You should check first thing (as already said) how the same hard disk physical and logical sector sizes are seen when connected directly to SATA or via the USB adapter. As well it is entirely possible that *something else* in the USB adapter creates the issues, the limit to 5 TB for the new ones is strange, and possibly the old one only seemingly works but introduces some kind of problem. On one side your using each and every (potentially crappy) third party tools is a good thing as it evidences their limits/issues, on the other if you throw at the disks many tools and they give different results you won't likely ever be able to pinpoint the underlying issue (provided that there is a single basic issue that creates different issues to different programs) Personally there are only two programs that I trust for troubleshooting this kind of issues, though they are not exactly "easy" to use: #1 gdisk: https://www.rodsbooks.com/gdisk/ #2 dmde: https://dmde.com/ Now, if you compare the GPT partition tables (as seen by gdisk p) created by the SAME tool on the SAME OS once when connected via USB and once via SATA, then maybe we can find out what the base issue(s) is(are). jaclaz

Trip, you are misquoting me, it's Microsoft that said that on that linked article, and - as said - it is a half lie, whether a UEFI implementation actually respects the UEFI specification and thus considers a 0xEF a valid ESP or it does *something else* (like using a "normal" 0x0B or 0x0C partition ID, possibly connected to the active status of the partition) as seen in the (given) raspberrypi example is a separate thing. Once the Winload.efi has been correctly chainloaded, one way or the other, how and from which device it happened becomes irrelevant, at the most Windows may decide to not mount the BCD in the Registry or prevent some boot (what MS calls system) device related features, such as hybernation). Now MS may well decide to not load/mount/access 0xEF ID partitions, but of course cannot make the same thing with traditional FAT volumes ID's such as 0x0B or 0x0C so if the motherboard's UEFI allows to chainload the bootmgr.efi on such a partition the (UEFI) boot will be successful. jaclaz

*Whatever* in the firmware. The "switch" between LBA28 and LBA48 happens (happened) at a much smaller size, if *something* has not LBA48,it has LBA28, and it "chokes" around 137 GB. So it is something else. jaclaz

Sure. GPT is "a part of" "UEFI", as well as MBR, again, that is the whole point. Microsoft decided to "narrow" the UEFI specifications, see in the article: https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/windows-and-gpt-faq?view=windows-11 As often happens with Microsoft, this is a half lie, as - at least up to 7 - it is possible to boot in UEFI mode from MBR disks with a few "tricks": https://msfn.org/board/topic/184850-is-windows-vista-possible-next-to-windows-11-on-uefi-mode/?do=findComment&comment=1250504 Now,. is it "smart" to boot from a MBR disk a Windows system that is officially not supported? Certainly not, as you have to add to the artificial limitations created by MS as heaven only knows which kind of deviations from the standard specifications were introduced by the various motherboard manufacturers in their UEFI implementations and what not. As well, is it "smart" to boot in BIOS mode from a GPT (hybridized or using one of the other loader tricks) disk? No, but it may be needed/useful in some cases. jaclaz .

No idea about what the warning you have relates to. Nor any idea about what DBR refers to. It could be something connected with the "conversion" from FAT32 you made or - more likely - from the 4KB to 8 KB[1] conversion[2]. You seem like using each and every (formatting/converting/partitioning) third party tool available assuming that all of them work properly (hint: very often they don't work as they should in a number of cases). As you have seen with your bunch of recovery tools (some of which written by the same people that wrote the partitioning tools) they often completely fail at something that a "normal" CHKDISK solves, so I wouldn't be so sure that they created "perfect" partitoning/formattinh/converting tools at the same time they wrote good-for-nothing recovery tools. The issue you had with USB "random" disconnection has no reason to be related to the filesystem used, but AFAIK it is not something that should happen, there could be *something* wrong in your XP install, in the USB drivers or even in your hardware, a rather common issue can be not enough USB power. jaclaz [1] as always, just my personal opinion on the matter, but I see no reason to have 8 KB clusters on a NTFS volume, the whole idea being that 4K clusters are good up to 16 TB and unless you are going to exceed that size, there is no advantage in a larger cluster size. [2] once re-said that I have no idea about what the error you got actually means, it is possible that converting to a larger cluster size a "twilight zone" is created at the end of the volume, and that this triggers that warning (essentially a mismatch on size in the BPB when compared to the volume extents as seen by windows and/or to the partition size) : http://reboot.pro/index.php?showtopic=18034&p=166592

Which reaction? No need to sue the Chinese, but knowing when something is incorrect usually helps in life. jaclaz

jaclaz

"UEFI/GPT-based hard drive" makes sense (particularly in MS jargon). "UEFI HDD" (particularly when compared with "normal HDD") makes none. jaclaz

Well, in the link you posted there is no mention of "UEFI HDD" nor of "normal HDD". https://www.addictivetips.com/windows-tips/select-boot-device-on-uefi-bios/ For all it matters, your motherboard firmware can call your hard disk "Goofy" and an external USB one "Mickey Mouse", and as well you are perfectly free to call them whatever you like.. In any case a hard disk is a hard disk and it can be either MBR or GPT partitioned, the whole point is that a lot of people confuses GPT with UEFI (like you did and insist on doing) , whilst the second does not necessarily imply the first.. When you switched everything to "normal" (in your jargon) you installed the Windows 7 in "legacy mode", as said before Microsoft - in their wisdom - introduced a limitation not allowing to install Windows 7 in UEFI mode on MBR disks, still that does not mean that GPT is required by UEFI. jaclaz

The file is downloadable only if you click on the link from the given page, not by directly clicking on the link (on another page, like this thread) to the file, it is - i believe - a security feature to avoid excessive (automated) downloads.. Yes, nlite should work fine, though it may depend whether the main OS install files have been fiddled with: https://msfn.org/board/topic/181433-nlite-slipstreaming-sata-drivers-for-windows-2000-sp4-install/ But check also the WinRAID guide: https://winraid.level1techs.com/t/guide-integration-of-intels-ahci-raid-drivers-into-a-windows-xp-w2k3-w2k-cd/25310 jaclaz

There are no such things as "UEFI HDD" or "normal HDD", there is GPT style of partitioning and MBR style of partitioning. BIOS is ONLY compatible with MBR style[0]. UEFI is (should be) compatible with BOTH MBR and GPT style, though often GPT is forced by some artificial limitation by either the firmware or the OS or both. https://en.wikipedia.org/wiki/EFI_system_partition The normal BIOS booting sequence (on MBR) is: BIOS->MBR code->PBR of Active partition in MBR partition table->PBR code-> OS loader or bootmanager The UEFI booting sequence (on GPT) is: UEFI->EFI loader on ESP (normally FAT32[1]) which has its own ID of C12A7328-F81F-11D2-BA4B-00A0C93EC93B The UEFI booting sequence (on MBR) is: UEFI->EFI loader on partiion (normally FAT32) that is considered the ESP (or EFI System Partition) with an ID of 0xEF (some wrong implementations may want to use the "generic" 0x0B or 0x0C[2]) jaclaz [0] though there are tricks/workarounds to boot GPT from BIOS, besides hybrid MBR's there are a few ways here: http://reboot.pro/topic/19516-hack-bootmgr-to-boot-windows-in-bios-to-gpt [1] though according to the specifications "FAT" is to be used, so also FAT12 and 16 should be possible [2] An example (solved): https://github.com/raspberrypi/rpi-eeprom/issues/126

The drivers are on his site, it is not that easy to navigate it, as it is mainly in Japanese. Is this the driver you want/need? (Intel Matrix Storage driver): https://win2k.org/blog/2009/04/17/813816 https://win2k.org/cgi-bin/dl.cgi?file=iata76_cd2kh.cab jaclaz

That's another thing, it is a "new" level of the UEFI specifications (UEFI Class-3), this class of hardware didn't exist in times of VIsta or 7, so it is not at all surprising. The surface/surface PRO installing of Windows 7 is talked about on another thread: https://msfn.org/board/topic/184183-how-can-i-install-windows-7-pro-or-ultimate-on-a-microsoft-surface-go/ As said before there may be "tricks" around that limitation. jaclaz

OT, good ol' joke about engineers and mathematicians (and physicists): jaclaz

You will need to start adopting mount points, they are possible since Win2k version of NTFS came out: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-2000-server/cc938934(v=technet.10) .https://www.itprotoday.com/windows-78/magic-mount-points My personal advice is to have on each physical disk a (can be very small) NTFS volume with the mount points of other volumes on the same disk, though mount points can of course be made cross-disk it is easier if they are self-contained. jaclaz

The post above yours is about removing entries in the Registry about a service, not about deleting files in a (protected by some system integrity provision) folder: https://ss64.com/nt/sc.html jaclaz

Though it doesn't seem at all like there is a RegEx expression anywhere in that. Anyway, the only important thing is that you are happy with your solution. jaclaz

NTLite has its own support forum/community board since several years: https://www.ntlite.com/community/index.php and it is essentially a commercial software, unlike the previous Nlite (which - years before - was largely developed and supported on MSFN), no surprise that is not (anymore) talked about much here on MSFN (I believe that many MSFN members that are NTLite users are also members of that official support board). jaclaz

Sure, but those businesses should (in theory) have experts capable of mitigating them, no need to (further) scare to death common users about vulnerabiliities they won't ever experience (simply because they don't use the affected services/programs). If we want to scare them, as general advice, we have the (evergreen) opinion by Armand Gracious : https://www.dedoimedo.com/computers/experts.html jaclaz