jaclaz

The common "Y" USB cable has two male USB connectors (one data+power, one power only) and a single female one, the idea is to draw power from two USB ports on the computer: https://en.wikipedia.org/wiki/Y-cable#USB but if you have an external power adapter (provided it works correctly[1]) then that is not the issue. You said you have USB drive cache disabled, have you tried deleting these small files with it enabled? It should be not *needed* on modern disks that have plenty of internal cache, but you never know, it could also be *something else* at the USB or Mass Storage driver level, but if it happened to you on two different OSes (Xp and 7) it is not probable. jaclaz [1] I have seen power adapters that behaved just fine but that in case of peaks of draw dropped voltage, so a test with another adapter is anyway a good idea

Yep, but you are roughly 99% right, 5 TB 3.5" disks are rare, they seem to "jump" from 4 to 6+. There is still (only for the record) the good ol' poor man's way of defragmenting (you won't like it, as it needs an extra hard disk). Back in (good ol') NT 4.00 times there was no defragmenting program included in the OS, and what I used to do was to copy all the files to another hard disk, delete (or even re-format, depending on cases) the "main" hard disk volume(s) and then copy back all the files. Of course it took (and would take given the size of your volumes and number of files, notwithstanding the increased speed of devices and buses) "forever", it is a lot of time since I did any test of speed, but if I recall correctly,. the throughput of imaging a disk should be between 150 and 400 GB/hour (with some particular fast programs on extremely fast devices topping at 600 GB/hour) , and copying should be much slower than that. jaclaz

These data losses may well be connected to Issues with the power draw from the USB connector. Those are USB 3.0, right? The limit should be 900 mA (@5V). If I were you I would try with a Y USB cable and see if the behaviour remains the same. jaclaz

Very good finding about the version of the Paragon GPT included in the HFS thingy. I am not sure to understand, the WD50EZRX does (or did?) exist: https://www.disctech.com/Western-Digital-WD50EZRX-5TB-SATA-Hard-Drive About exFAT, yes, I am not much familiar with that filesystem, but Defraggler and UltraDefrag should be able to defrag it (there may be many more third party tools capable of that) since it is a not a very common filesystem and support on XP for it was added as an afterthought I wouldn't be surprised if there is a "main" version of it (that XP can access just fine) and some later versions or sub-versions (that in some cases XP has trouble with). The defragging (by this or that third party utility) may well make the filesystem backwards-compatible with the version supported in XP. jaclaz

One can use Nirsoft's Serviwin to see which file corresponds to which service, though that won't work for svchost.exe "hosted" services. jaclaz

Recent (like in the last 10-15 years) ATX PSU's have generally short circuit and overdraw/overcurrent protection, i.e. if you draw too much power they will simply switch off, but it is not necessarily true, el-cheapo, no-name PSU's may well lack this form of protection, though it would be an exception. And there is no way to know[1] for sure. Additionally, there is no easy/cheap device to actually test a PSU behaviour under load, all the testers that you can find are essentially multi-channel voltmeters, they are used to verify that a PSU is providing voltages within specs without load (or with a minimal one), what would be needed is a series of shunts or an electronic load, such devices can be found for several hundreds of dollars at a minimum and, given the high amount of Amps (or Watts if you prefer) involved you would need particularly beefy ones. There are many "PSU calculators" available but the results they provide (given that your hardware is listed on them) are - in the best case - a vague approximation of the real power needed, and - on the other hand - a PSU. particularly if old/used may well still work fine with a lower load but fail if too much Amperes are required by the motherboard or devices. As well, there is software that can check load/power but it depends on sensors that your specific hardware may or may not have https://openhardwaremonitor.org/ A better approximation would be using a surely powerful enough PSU with the actual hardware, first checking how much the PSU draws form mains socket and then with an amperometer/multimeter how many amperes are drawn on each rail. It is anyway a lot of work, not worth it (IMHO) unless you are trying to optimize a build for some particular reason. Try estimating the needed power via one or two of the online calculators, and if the result seems roughly compatible with your PSU, try it, if it overdraws current in 95% or 99% of cases the protection will kick in and switch it off without damage, in the remainling 1%-5% it will release the magic smoke and you will have to buy a new (more powerful) PSU (which you would need anyway, the differnce would be only about having an old spare working 450W PSU or not). jaclaz [1] you could - in theory - put a fuse on each voltage line/rail

It greatly depends on what is "broken". The \Program Files folder in itself is pretty much "portable", it is (mainly but not only) the Registry and drivers that are linked to the specific install/machine, generally speaking, bar the standard default files in a pristine install, it is difficult if not impossible to recreate (in a VM or on real hardware) an "exact" copy of the \Program Files folder (some programs that were installed on the old machine might be missing, or you may add by mistake some other versions and the old Registry entries won't be valid. I am not sure to understand how you plan to operate, what do you mean by "dock"? Depending on the size of your hard disk, how much space you have, etc. it would probably make more sense to install a second instance of XP on another volume/partition and then try to do the copy/paste of the missing/broken files, i.e. make first a dual boot system, and then use the second instance to source the files for the old install, but it is a looong, complex repair attempt without any possibility to know the chances of success unless first the reason why the old XP install has "broken". I mean if the disk/partition has issues and caused the error(s) corrupting files or making them disappear, it is not likely that by copying them over the OS will be any better. jaclaz

Yep, sure , those are 1 TB hard disks, not 1 GB ... I was just having a little bit of fun at your typo, 1 GB hard disks were common around 1995 or 1996, maybe earlier, and of course they were IDE or SCSI, SATA specifications were first released in 2000 and it took some time to become common, but by then (2003) the minimum capacity of (SATA) hard disks was more like 40GB or so . jaclaz

There are basically two ways to access an "external" Registry "backing file". #1 is mounting the file as a (temporary) hive in the "current" Registry (this can be done with the "normal" Regedit), for an example look here: https://4sysops.com/archives/regedit-as-offline-registry-editor/ #2 using an "offline" Registry editor such as: http://reboot.pro/index.php?showtopic=11312 For what you want to do the "normal" #1 way is "better", but it is what you want to do that is extremely complex and that is difficult or impossible with *any* method, as it would imply hundreds or thousands of settings, many of whlch may be contrasting with your current Registry. In theory you could load one of the old windows Registry backing file as a temporary hive, select and export the relevant keys to .reg file, manually edit the .reg file (to change the temporary hive name to the "real" one) and import the .reg file in the "current" Registry, but as said likely we are talking of hundreds of small .reg files and a mistake may always happen. Besides, the .reg file does not "carry" some metadata (authorizations) so that when you import them the authorizations may be incorrect for some particular keys. jaclaz

Oops, sorry, my bad. 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