jaclaz

It could (or it could not) be. The disk is seen (directly or indirectly) as SCSI. There is *something* in the SCSI commands that was limited to 32 bit in older implementations, but no idea if it is connected/applies to your case. Since the disk is not seen in Disk Manager you may be right, or maybe not, I don't really know. jaclaz

I thought that using "Scan for hardware changes" would have worked, maybe it depends on the controller or on the OS or on both. jaclaz

Maybe HotSwap would be useful? http://mt-naka.com/hotswap/index_enu.htm jaclaz-

Yep, though still we don't know if the issue is there or it is in the controller inside the external case. Dave-H is known for having in the past managed to find the least compatible to anything external case , JFYI: https://msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ https://msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/ maybe he is trying to set a new record... (besides, he is already the forum champion in "let's find the laptop with the least supported touchpad ever", but that's another story ...) jaclaz

There is a third possible position, let's call it "climate change ignorant" or ,"climate change agnostic" someone that believes that noone actually knows what is happening[1] (and why it is happening). [1] or not happening

Not my field of expertise (I always used and still use only IP static addresses on my networks, bar the Wi-FI). The 169.254.x.x nebtmask 255.255.0.0 is "normal", it is a so-called APIPA address, it is actually a symptom, it means essentially "the network stack is set to get an address from a DHCP server, but none could be found, so I am using temporarily this address": https://www.techtarget.com/whatis/definition/Automatic-Private-IP-Addressing-APIPA But what happens if you manually set a static IP address? If everything works, than the issue is only related to the DHCP, if it doesn't there may be "wider" issues with the network stack. What do you get with: ARP -a in the case of a missing DHCP and in the case of the static address? jaclaz P.S. Also, check the Registry in: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\VXD\DHCP in it there may be one (or more keys) like DHCPINFO00, DHCPINFO01, etc. Save/backup them (just in case), then delete them and reboot.

Well, the good ol' method was to use a car tail lamp, double filament, 5/21 Watt @12V. The 21 W on the 12 V rail, the 5W on the 5 V one. On older PSU's you had to have some load on both rails.

Hmmm. Never heard of Plop, right? https://www.plop.at/en/bootmanager/features.html

No, not really. If you connect the disk directly you bypass a number of things, including the connector, but also the enclosure controller and/or the e-sata card you may have on your PC. If a connection (intended as EVERYTHING is between A and B) works with a given OS BUT does not work with another OS it is NOT an issue of the cable or of the connector, it is an issue with the software (driver of the controller or *something else*). You have three different layers of possible incompatibility: 1) the disk partitioning style (that is NOT supported in XP if not through the Paragon software) 2) the disk size (that may or may not be supported by the OS) 3) the driver of the controller and/or of the add-on e-sata card (that may or may not in the version for XP have the same capabilities than the version for 10), I have seen you posted a reference to a (pseudo/virtual) SCSI path: \Device\Scsi\SI31121Port5Path0Target0Lun0 and Scsi devices are known (not necessarily it is your case) to have drivers using 32 bit-limited Scsi commands. If the enclosure has an external power supply, you could try one of these simple cables: https://www.startech.com/en-us/cables/esataplt18in (of course if you have a free sata port on the motherboard) jaclaz

No, strictly speaking, you haven't. You partitioned it as GPT or - even better - you initialized it as GPT. Then you created one or more partition(s) or volume(s) in it, and then formatted this/these partition(s)/volume(s). The sector address you are having an error with is not very high 0x5bc5e0 is 6.014.432 which multiplied by 512 (sector size) makes 3.079.389.184 bytes offset, it doesn't seem connected with the size of the disk. Anyway, if you haven't already done so (i.e. if you have now only one huge 3TBish single partition/volume), I would try to make two partitions on that disk, the first one within the 2 TiB/2.2TB limit, and a second one for the rest. This should eliminate or reduce possible conflicts with this (or that) 32 bit limit, at least for the first volume/partition. About the HFS error, if a find is not found and if the service doesn't start, not a surprise that it doesn't show in Disk Manager. You will have to trace with filemon or procmon to find which file is missing/is not found (if any).

I have not much experience with these settings, but I remember how sleep on Vista and 7 can be troublesome. Have you already gone through the steps proposed here?: https://www.vistax64.com/threads/power-options-and-sleep-mode-problems.63567/

Usually you choose it when you use the Open With, choose a program that is not in the list and check the checkbox "always open with this program" or similar, but a number of programs will also associate with a given file type when running, I believe. I think it is somehow intertwined with "file association": https://learn.microsoft.com/en-us/windows/win32/shell/fa-how-work jaclaz

Yep, it is now an old software, still available (as an example) on Softpedia: https://www.softpedia.com/get/Others/Miscellaneous/tiny-hexer.shtml jaclaz

I don't think that disk management/diskpart will allow you to shrink that partition. Personally I would use directly a hex/disk editor, but of course it isn't advisable if you are not familiar with one or you don't want to waste some time learning how to use one. In case you are interested, since you are also running XP[1], I would suggest you good ol' Tiny Hexer, optionally with my MBR view script: http://reboot.pro/index.php?showtopic=8734 Your mission, should you accept it , is to change four bytes in the partition table (second entry): 976771071=FF57383A should become 721614847=FFF7022B so, actually, three bytes. jaclaz [1] it should work just fine in Windows 7, but if I recall correctly Windows 7 has a mechanism to protect the MBR so - again if I recall correctly - the disk needs to be put offline (or maybe it was the PBR that had this protection? )

I cannot say "why" you have that situation, but you have a hole between sdb1 and sdb2. Please follow me. sdb1 starts on sector 2048 (right) it is 67149824 sectors in size which is evenly divisible by 8 (as the device has a physical sector of 4096 bytes it is 8 x 512 bytes or 8 logical sectors), disk management/diskpart normally creates "rounded to megabyte" partitions and 32788x1024x1024/512=.67149824 so this is also "right". sdb2 starts on 67167765 but, (and this is "queer") before it you have 2048+67149824=67151872 so WHAT is this hole of 67167765-67151872=15893 sectors? sdb2 is a an extended partition, the unused sectors for the extended partition would anyway normally be - again - 2048m so everything would remain alignedm but sdb2 has an odd number of sectors, 310423995, which make no sense to me, unless this extended has been aligned to the cylinder (I just checked it is, it virtually starts at CHS 4181/0/1 and end - like the logical volume inside it - at CHS 23503/254/63). Also, sdb5 is the actual logical volume inside extended, but it starts at 67167828 and 67167828-67167765=63 which is the "old" offset. So, it seems to me like you used the "new" Windows 7 partitioning for just the first partition and then you used XP (or another "old" convention tool) to create the extended and the logical volume in it. jaclaz

No, no, no. Partition alignment has nothing to do with partitioning style. It is not particularly smart to have a GPT disk aligned to cylinder (i.e. with 63 sectors before first partition) but it is technically possible, as in most implementation of GPT at the most 32 sectors are used for the GPT Partition Table (which is not 2048 sectors) the GPT uses: LBA 0 Protective MBR LBA1 GPT header LBA2 - 33 Partition entries (each takes 128 bytes so 32x4=128 max number of partitions) So 34 sectors for the whole stuff. Windows VIsta and later when partitioning will align to 2048 sectors INDEPENDENTLY from the style (MBR or GPT) you choose. You DO NOT want to use GPT: GPT is not compatible with BIOS and it is not compatible with XP booting, ONLY use MBR. You can have alright a MBR style partitioning with Mbyte alignment BUT you should NOT use EVER the XP disk management IF you have on the disk logical volumes inside extended. The XP disk management has no issues with primary partitions, only logical volumes inside extended are at risk. jaclaz

Well, for whatever reason your initial partitioning did not respect the "new" paradigm (that - just for the record - is not sector 64 but rather sector 2048). If you are dual booting XP and 7 you risk (unknowingly) to lock yourself out of all the logical volumes inside extended: http://reboot.pro/index.php?showtopic=9897 (if you are using the "new" alignment AND use the XP disk management, once you have parittioned with the new alignment NEVER use the XP disk management on that disk/ssd) The old paradigm was "align to cylinder" (hence 63) while the new one is "align to Mbyte" (hence 2048 as 2048x512=1048576). The setting for this behaviour is - since Vista - in the Registry, it is a set of four keys in CurrentControlSet (that could be ControlSet001 or ControlSet002): HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\LessThan4GB HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\Between4_8GB HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\Between8_32GB HKLM\SYSTEM\CurrentControlSet\Services\VDS\Alignment\GreaterThan32GB The defaults are 1048576 for the last three and 65536 (128x512=65536) for the first one, for smaller devices, as said it started with Vista and all later Windows use the same, here are some details for Server 2008: https://frankdenneman.nl/2009/05/20/windows-2008-disk-alignment/ The 64 sector offset was used by a few hard disks, but is not common. Check that you have these keys with the default values in your Registry, then if you partition normally using Windows 7 Disk Management the partition will have the "new normal" 2048 alignment. jaclaz

It seems like you miss: HKEY_CLASSES_ROOT\*\shellex\ContextMenuHandlers\Open With default should be set to {09799AFB-AD67-11d1-ABCD-00C04FC30936} See also: https://www.nextofwindows.com/how-to-add-the-missing-open-with-option-back-to-context-menu-in-windows

It seems like actually 5 were recovered: https://forums.lostmediawiki.com/thread/11868/old-british-software-early-2000s (but seemingly no links to get them) jaclaz

I don't know, but I wouldn't be surprised that the .zip "integration" in Windows does anyway access *something* (possibly the index) in the .zip file when right clicking on it. If this is the case, then maybe some specially crafted .zip file could cause issues (I am thinking of so-called Zip Bombs or similar). Something similar (cannot say if it is your case) was (is?) caused by the (stupid) "it came from internet" alternate data stream in NTFS (Zone Identifier). jaclaz

<reserved>

Yes, testing the splitter with a multimeter would be wise, to get the contacts in the female sockets you can use a short piece of copper wire, like the one you can get from a CAT5+ cable. There is a very similar cable, with a male Mini Din 6 and two female Mini Din 6 that is used for some kind of S-video connection that has a completely incompatible pinout (though - to be fair - in those plugs and sockets are black and red, not the "standard" green or purple). Being anyway PS/2 ports/device, it is a good idea to NOT hotplug/unplug any device or cable, things should be connected/disconnected with motherboard off, modern motherboards should have electronic fuses, but you never know.. If you look around for this kind of splitters, you will find quite a few "bad" reviews by (presumably clueless) people lamenting that both a keyboard and a mouse work when connect to the green (or purple) socket of the female but that both a keyboard and mouse do not work on the "other" socket blaming the splitter (while I suspect it is simply the 2 and 6 not connected to anything on the motherboard socket). jaclaz

The "common" pinout is also on Wikipedia: https://en.wikipedia.org/wiki/PS/2_port On "normal" PS2 port pins 2 and 6 are not connected to anything, on "combo" ports they are connected to a secondary +DATA and +CLK, but it seems like - as always happens - it is not a "proper" standard. AFAICU each manufacturer using these stupid combo ports uses its own design, some use the "normal" 1 and 5 pins for the keyboard, and the 2 and 6 for the mouse, someone the exact opposite, but it should only be a matter of inverting the devices on the female sockets of the Y splitter. BUT some manufacturers intend that double coloured port as keyboard or mouse one meaning that you can connect to it either a mouse or a keyboard, i.e. only the 1 and 5 are connected and 2 and 6 are not connected (as in any normal PS/2 port) in which case the splitter cannot work as there is nothing to split. I suspect that Asus - at least for desktop motherboards - is of this latter kind, the (stupid) idea is that you have only one "old" P/S2 device (mouse or keyboard) and you can connect it to the port, and have the "other" device a new, USB one. jaclaz

As said in the other thread: *any* Windows later than NT 4.00 will update the NTFS filesystem, this shouldn't make it unbootable unless the actual NT 4.00 install is pre-SP4, so - maybe - what you are experiencing is another issue besides the NTFS filesystem version updating, specific to Windows 10 :unsure:. I don't think there is any way to prevent that and surely there is no way to convert the volume back to the old version of the filesystem, at the time (Windows 2000) it caused lots of issues, see also: Using a (windows 8+ based) PE (and possibly also a full install, but I am not sure about the latter) there are Registry settings (Sanpolicy) that can be used to prevent the volume from being mounted (thus allowing as an example to clone it or make a RAW image of it) but the moment the volume is mounted by a later windows the filesystem version will be upgraded: http://reboot.pro/index.php?showtopic=19687 I don't think (but I cannot say for sure) than anything bad can happen with XP and later NTFS, the issue is only connected with the NT 4.00 (for sure) and Win2k (maybe) NTFS versions. The NtfsDisableLfsUpgrade Registry key you mention is only about the upgrading of the Log file format, but this should only - in the worst case, when a volume is not cleanly dismounted - prompt to run chkdsk when the disk is back in the older system: https://en.wikipedia.org/wiki/NTFS#Journaling it makes sense to have it when mounting an older disk/volume, anyway, I believe it is not only limited to 8, and it still works on later OS, but of course need to be tested: https://social.technet.microsoft.com/wiki/contents/articles/15645.windows-8-volume-compatibility-considerations-with-prior-versions-of-windows.aspx jaclaz

That happened (a lot) when Windows 2000 came out (as 120 days trial). The NTFS filesystem is updated (silently, without warnings or messages) to a higher version, incompatible with NT 4 (some compatibility has been introduced in SP4). A "vanilla" NT 4.00 install CD won't recognize the filesystem, you need an install media with integrated the minimum SP4 that takes into account the changes, see: Here is a reference on how to make a NT 4 install media with integrated SP6, but YMMV: http://reboot.pro/index.php?showtopic=2383 https://bearwindows.zcm.com.au/winnt4.htm jaclaz