jaclaz

Yep , only issue being that on a SSHD : https://en.wikipedia.org/wiki/Hybrid_drive you won't know if reads are cached or not, that may be a huge roadblock to this otherwise nice plan. BTW a number of slow sectors (in reading) does not say much about the reliability of a drive. Talking of conventional drives, anecdotally I have a machine equipped with a very, very old SAMSUNG (around 4.1 GB in size - I know, I know) that had a number of "slow sectors", that at the time I got for free (discarded because owner thought it was nearly dead) and that happily spinned away 24/7 since 2001 (that is roughly 16 years, I replaced the whole machine in March or April 2017 only because I needed to update the OS - NT 4.00 - for other reasons. ). jaclaz

Sure, but still, it is a non-problem in practice. With the only exception of NoelC, noone on this board EVER used it (or if anyone did, they were pretty quiet on the matter). It should mean something about the popularity of the filesystem among both "common" users and "geeky peeps" and in any case I am pretty sure that the latter category would find a way to create a REFS filesystem (by using -say - a VM with an earlier-than-Fall-Creators-Update-version of Windows 10 in - still say - a VM). On other (old) news, when they released XP the demented MS guys did remove something useful (the Wang/Kodak Imaging tool) that was a nice (very popular) tool on 9x and NT/2K, and, in no time, each and every "geeky peep" on the internet managed to port the 2K version to XP (and a subset of the "geeky peeps" also use it on Vista and 7 ): http://kakopa.webcindario.com/imaging/ that was a problem, and it has been solved just fine, when/if making a REFS will become a problem, surely a workaround will be found. As said they also removed Outlook Express, doing the same operation (taking away a thing, that was previously given) but I don't think anyone will be whining about this removal. jaclaz

Well, it is a filesystem aimed to storage, and it makes sense that it will be reserved to "high end" editions of Windows. Nothing "wrong" in the fact that a "common" user (which wold anyway have no practical use for it) is prevented from creating a new filesystem. BUT there is something really interesting in the doc you linked to: https://support.microsoft.com/en-us/help/4034825/features-that-are-removed-or-deprecated-in-windows-10-fall-creators-up at last Microsoft realized what is the real nature of Outlook Express . jaclaz

I see now, according to you it is the same thing to make a serious conceptual error (such as stating that it is not possible to access the MBR through a USB connection and presenting a PBR or VBR - BTW a NTFS one, 16 sectors long - as if it was a MBR, without understanding what they represent) and a - anyway debatable - case of small/CAPITAL letters typo in a measurement unit symbol. Good to know . JFYI, and to be as picky as you seemingly are: The 28-bit "barrier" happens on (2^28-1)*512=137,438,952,960 bytes, i.e. at roughly 137 GB or 137,438,952,960/(1024^3)=128 GiB. Oh, and before I forget: I did state (and it was obvious) that the bootsector invoked BOOTMGR, but of course that could be any Vista or later OS or *any* other file renamed to BOOTMGR. jaclaz

First thing first. S.M.A.R.T. (what I personally call "D.U.M.B.[1]) is a failed attempt at pre-cognitive technology that invariably delivers almost - but not quite - entirely unlike reliable info. The way the S.M.A.R.T. data is recorded (in non-standard ways) and the way it is interpreted (in non-standard ways) by largely un- or mis-documented non-standard tools on non-standard (and completely undocumented) devices are simply appalling, and how they are presented to the final user it is - if possible at all - even worse: https://docs.slackware.com/howtos:hardware:smart_hdd_diagnostics The ONLY (and only partially) meaningful S.M.A.R.T. parameters that may predict an imminent failure are reporterdly: https://www.backblaze.com/blog/what-smart-stats-indicate-hard-drive-failures/ 5, 187,188,197,198 and - possibly - 189. They are all just fine on your disk drive. Solution 1: Flip a coin. If it comes out head, YES, you should change the device as soon as possible, if it comes out tails, NO, your device is just fine. (the above test, on average, has the same accuracy than a S.M.A.R.T. diagnosis) Repeat the test every 6 to 12 months. Compare with: https://en.wikipedia.org/wiki/Flipism Solution 2: Make sure you have a recent, reliable backup of data. Make sure you have a second copy of the above backup, on a different media and possibly kept in a separate location. Keep maintaining the two copies of backup. Live a happy and long life, without worries about the device failing. When the SSHD device will fail, it will fail [2], just get a new one and restore from the backup. jaclaz [1] Definitely Unreliable Measurement Bull§hit [2] ... and it will fail without any warning, and surely not a warning coming from S.M.A.R.T. data, or it will simply continue to buzz along happily until you will have changed the whole computer ...

Good to know 0x49 should be "dec ecx" quite "strange". In this case IMDISK is just some means to mount a volume easily, the mechanism involved and the results of the experiments came/come from the "standard" XP detecting/mounting. @98SE Just to show off a bit find attached the output of the batch you can find here: http://www.msfn.org/board/topic/152097-on-superfloppies-and-their-images/?do=findComment&comment=1001712 on "your" last posted bootsector (please note that it is designed to work ONLY for FAT12 or 16 bootsectors). jaclaz

Just in case, previous related discussion/findings: http://www.msfn.org/board/topic/152097-on-superfloppies-and-their-images/?do=findComment&comment=987482 jaclaz

Come on , think a bit before making these kind of incorrect statements . Of course the MBR is perfectly accessible on a USB disk, otherwise you wouldn't be able to access partition(s) on it (or to re-partition it). A USB disk drive (like any other mass storage device) exposes a \\.\PhysicalDrive object in any NT base system (i.e. what you see in disk management) and of course ALL sectors of a \\.\PhysicalDrive are accessible. The sector(s) you posted is NOT the first sector of the external disk drive, it is at offset 63, and it is the PBR or VBR. That you (or the software you are using) are incapable of accessing the MBR of that disk is another thing. You can get a "better" disk editor (such as the Tiny-Hexer I posted a screenshot of) that will be capable of accessing the \\.\PhysicalDrive just fine (and BTW will default to the "correct" 16 byte view), or get any of the tools suggested by the Starman, such as HxD: http://thestarman.pcministry.com/asm/mbr/BootToolsRefs.htm More generally, if you could take some time reading the Starman's page on MBR and PBR/VBR's it would surely increase your understanding of the matter and help you avoid making these erroneus statements. WHY? I mean what particular "news" do you believe it contains? It is another bootsector, this time FAT16, invoking as well BOOTMGR, and as well with 63 sectors before, 4192865 sectors in size, 512 bytes/sector i.e. roughly slightly less than 2 Gib, with a cluster size of 64 sectors or 32 Kb, nothing particular about it at first sight. Analyze it yourself, it would be the perfect complement homework to actually put in practice what you will learn reading the Starman's pages: http://thestarman.pcministry.com/asm/mbr/index.html jaclaz

For the record jaclaz would describe it as Vista SP3. (Vista SP2 actually exists and more or less amounts to the only actually working version of Vista). jaclaz

Naah. First physical sector of the disk (or \\.\PhtsicalDrive) is the MBR. What you posted is NOT the MBR, it is the PBR (and starts on sector 63 of the disk, i.e. on first sector of the volume). You somehow chose the Volume instead of the \\.\PhysicalDrive in Hex Workshop. I posted an image of the data with its common interpretation, and from it you can easily see which tools I used. By convention these data is visualized in 16 byte wide format, not 14. jaclaz

It is difficult to say. The issue with letting the "revived" device be "autodetected" is the risk that the automatic repair provisions (chkdsk via autochk or similar) may make things worse (it doesn't normally happen , but you never know ). As a matter of fact, presuming that the volume was NTFS formatted, it is not like there are that many ways (besides CHKDSK) to repair the filesystem, but it is always preferrable to have a RAW copy before letting the CHKDSK run, and in any case it is normally a good idea to run it in stages, the first time without the /F parameter, just to check what it says without (almost) writing anything to the volume. To make a RAW image you need (besides a disk with a volume with enough capacity to hold the whole disk size and with a suitable filesystem such as NTFS or EXT2/3/4, etc.) *any* dd-like tool, see: https://www.linuxquestions.org/linux/answers/Applications_GUI_Multimedia/How_To_Do_Eveything_With_DD since here you are dealing with a possibly damaged/unresponsive disk, it would make sense to use a dedicated program such as (Linux) dd_rescue: http://www.garloff.de/kurt/linux/ddrescue/ which - mind you - is not ddrescue: http://www.gnu.org/software/ddrescue/ddrescue.html Under Windows for making the image (or chunks of it) DataRescueDD: http://www.datarescue.com/photorescue/v3/drdd.htm is usually advised, otherwise I would personally go for DMDE (while this is a "full" data recovery too that implies some understanding of the matter the imaging part is simple enough for the common user): http://dmde.com/ that has also a command line Linux version (which I never personally tested and that most probably is complex in usage). jaclaz

And the MBR you posted is a PBR or VBR or volume boot sector, NOT a Master Boot Record. . However it is interesting a 14 byte wide visualization. jaclaz

Which contacts did you insulate? i.e. motor or heads ones? Or did you completely remove the PCB? In some cases the contacts between the PCB and the disk may be "irregular", in wich case a good idea may be to use a pencil eraser to clean the contacts and/or use a (teeny-tiny quantity of) electric contact cleaner and/or (sometimes needed) tighten a little bit more the screws. Also, do not underestimate the possibility that the actual SATA cable is bad (the SATA connector is re-known to have been poorly engineered and to come loose after a finite number of insertions/removals). First thing (after having made sure that contacts between PCB and disk are clean would be to try anothe SATA cable, new and/or surely working, and try the disk on another machine (most probably not your case, but you never know which kind of mess can be a Registry and what issues it can create) or use (on the same machine) a definitely "clean" environment, such as a PE or a Live Linux distro. More generally, you don't really want to access the volume(s) on the disk (on Windows, say via Explorer) you actually should be ready to image the disk (of course if it can beseen as \\.\PhysicalDrive), it is not uncommon that while the disk (the \\.\PhysicalDrive) is "revived" *something* is stil amiss/corrupted, preventing the volumes in it to be mounted and assigned a drive letter. Once you will have managed to make an image of the \\.\PhysicalDrive, then it will be possible to (hopefully) check it and recover the volumes or the files. jaclaz

And you still miss the point, besides the utter futility of your fictional USB disk drive with 21 partitions and the second one with 24. A mountvol set of commands can be easily scripted in such a way to fulfill your completely crazy request, but then you will start moaning about the need of running a program when you insert the USB device, and I would reply that you could have the batch residing on the USB device and be activated by Autoplay, but then you will promptly reply that you have obviously Autoplay disabled on USB devices, and I could reply that there is no problem in coding a service to watch for USB connection triggering the script, and then you would of course introduce some other artificial limitation (like "I don't want a watcher service running"). I see that it's lost time , have fun creating fictional non-solutions to non-existing problems. jaclaz

No, it doesn't make any sense whatever, The problem with drive letters came out in NT times, this is 20 years ago (or so). It has been already solved by mountpoints, that are available since the NTFS coming with Windows 2000 (that is 16 years ago), and of course they are perfectly transparent to the OS. https://technet.microsoft.com/en-us/library/cc938435.aspx https://technet.microsoft.com/en-us/library/cc938934.aspx As long as you have a single NTFS volume, you can make in it as many folders as you want and map to each folder a volume, this way not only you have a virtually unlimited number of accessible volumes, you can also name them in a more meaningful manner. You can have (say) D:\100> Example screenshot attached. jaclaz

I have noticed that you often mention the "consumption" of drive letters. JFYI, this problem was solved with Windows 2000 by using mountpoints on NTFS. jaclaz

Sure , try changing the active partition in XP Disk Manager on a MB aligned volume. http://reboot.pro/topic/9897-vistawin7-versus-xp-partitioning-issue/ jaclaz

More than that, a 3.5" disk needs two voltages, 5V and 12V, while the USB (besides the limited current of 500 mA that can be delivered through it in USB 2.0 or 900 mA in USB 3.0) only provides the single voltage of 5V. In theory - and this is just theory - provided that an USB port capable of delivering enough current such as a USB-C that can go up to 1.5 or 3.0 A it would be possible to have a voltage elevator to provide the 12V from the 5V and if/when a suitable port and USB cable conforming to the newish PD protocol: https://en.wikipedia.org/wiki/USB#Power_Delivery_.28PD.29 also voltages of 15 V (that can be easily reduced to 12 V) might become available. jaclaz

98SE Really, it is ALL written up ALREADY in this thread, please RE-READ (and re-read again, and again the related posts) NO value higher than 0xFFFFFFFF is possible in any of the 2 fields related to LBA addressing (Start Address and Size). There is NO space for any bigger value. Imagine that you have a cabinet with 8 drawers, each drawer can either contain one single object (and no more than one). How many objects can you store in the cabinet? 8 and no more than 8. Now you have a field 8 characters in length, how many characters can you store in this 8 characters field? 8 and no more than 8. Since allowed characters are 0123456789ABCDEF, knowing that F represents the bigger possible number, what is the biggest you can write? FFFFFFFF and no more than FFFFFFFF Now these are hex numbers, you can use Windows calculator to play with them just fine, 0xFFFFFFFF (hex) is 4,294,967,295 (decimal). What happens if you sum 1 to 0xFFFFFFFF? Here: 0xFFFFFFFF+0x1=0x100000000 you need 9 characters, as the 8 you have available will be 00000000. Sure , this is what we (highly specialized tehnicians) call "logical volumes inside Extended Partition" and exists since DOS 3.2 or so. The only issue here is that the Extended Partition "contains" the logical volumes, so it must be bigger that the sum of all volumes inside it, with a maximum size of - guess it - 0xFFFFFFFF. Would such an Extended Partition with a "fake" (limited to 0xFFFFFFFF size) work nonetheless through the chain of EMBR's (notwithstanding the name RLoew used, this is another thing, the term EMBR is commonly used to indicate the Extended MBR's that allow indexing logical volumes inside the Extended partition). So the Extended has values: 0x00000800 0xFFFFFFFF <- i.e. it begins at offset 2048 and extends for 4,294,967,295 sectors The values for the first volume in the EMBR at 0x00000100 are as well: 0x00000800 0xFFFFFFFF<- i.e. it begins at 2048+2048=4096 and extends for 4,294,967,295 sectors Now where would the next volume begin? At 2048+2048+4,294,967,295=4,294,971,391, i.e. 0x100000FFF that - once written in the space available will become 0x00000FFF, or 4,095, neatly beginning before the first volume. Sure, it is just a matter of writing a driver (a kernel one will be needed for having the disk bootable) capable of accessing the whole disk RAW and create an on-the-fly structure virtually combining two or more extents in a single virtual volume. The hint about a (super-)floppy (that you didn't seemingly catch) by cdob is actually an interesting one, however. and could well be the target for a further experiment. Most probably a filter driver (such as the reversed dummydisk,sys) to make the hard disk a "Removable" (please read as "non-partitioned") device might be needed (or maybe not) for the test on an internal disk. The test on a USB super-floppy makes little sense since (if) the USB adapter already translates sector size to 4 Kb, there are no issues up to 17.6 Tb, thus it sounds more than anything else a solution in search of a problem. It would be needed an USB adapter capable of accessing >2.2Tb disks while NOT translating sector size, which looks even more pointless. jaclaz

Or maybe it was the error angel (diverting all Dibya's typos from his code to board posts and particularly other people's names) jaclaz

Sure. Though #2 is not entirely accurate, I don't think we have any actual report of UNIATA working in such a setup, We know that UNIATA has internal Read16/Write16 support, which should be part of what is needed, but not necessarily *all* that is needed and not necessarily other possible issues that may come from other drivers involved can (or will) be solved. What we know is (and that may depend on specific hardware and what not), there is a common problem about 3 Tb disks not seen properly (i.e. seen as 746 Gb ones) by XP whilst there are reports of such drives being seen just fine with XP but with access (in Disk Management) limited to the first 2.2 Tb (which is "normal" and what also your successful experiment with Windows 7 confirmed). For some reasons it seems like most people that have such hardware are not properly documenting their setup (both those that have it working, limited to 2.2 Tb and those that see them as 746 Gb) so it is difficult to understand what is happening and the reasons why, just like it is not clear (in your unfinalized experiment) why the UNIATA wouldn't install properly. jaclaz

Well, thank you, but I decide myself what I will call bootable. Of course any real mode Operating System will be easier to boot than any OS with protected mode/HAL, and RLoew already reported that he can boot DOS/9x from 4k drives, though some modification to kernel files were needed. What you still seemingly miss is that whatever your tests are, all the rest of the world has already found ways to boot 2K and later NT based OS's from a USB device (with "normal" 512 bytes sectors), as I tried telling you, the fact that you are stuck on a - wait - let's see if my crystal ball is still tuned - 0x0000007b STOP ERROR, is not in any way "news" and it is a problem solved since 10 years or more. Until you will have had the time to get in sync with these last 10 years of developments, and fully understand how it works (or can work) allow me to doubt that you will be able to boot *anything* from a 4 Kb sectored disk. I am not following you. I never did any test in 2012. I referenced a 2012 thread where it was posted the confirmation that larger than 2.2Tb work fine in a USB enclosure that translates sector size to 4 Kb. I also referenced a 2015 experiment in making a particular partitioning scheme so that the same drive (1 Tb) could be accessed BOTH when the exposed side of the sector was 512 bytes AND when the exposed size of the sector was 4 Kb. Why would one want to change the controller behaviour (since that specific behaviour is what actually allows larger disks)? Or what would one want to replicate or improve the adapter, it already works just fine. jaclaz

Yep, we had some experience with one of those on a 1 Tb drive, JFYI: http://www.msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/ http://www.msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ The interesting part in that was that the particular enclosure had both eSATA (untranslated, i.e. 512 bytes/sector) and USB (translated to 4 Kb/sector) connections. Not actually "blow my mind" (surprisingly very few things may have this effect on my mind) but surely I would be surprised, since you do not appear to have (yet) the kind of knowledge (or experience) related to booting (particularly about booting a NT system, and booting it from USB). I am not sure to understand what you mean. Which functionality? Identical to what? Or document what? jaclaz

Most probably mangoes. jaclaz

Since this is the ONLY relevant piece of info (and it is a detail missing in the original post) I will state it. Most (if not all) USB enclosures designed for larger than 2 Tb hard disks use an internal translation of sector size, exposing to the OS physical sectors of 4 Kbytes. This simply means that the infamous 2.2 Tb limit (given by (2^32-1)*512= 2,199,023,255,040) gets instantly shifted to 8 times (4096/512) that value, i.e. (2^32-1)*4096= 17,592,186,040,320). Since the sector size exposed is 4 Kb (and not the "normal" 512 bytes) the disk won't be normally bootable. Nothing really new. A couple 2012 threads: http://www.msfn.org/board/topic/157117-running-3tb-drive-on-xp-over-usb-issue/ http://www.msfn.org/board/topic/158361-confirmed-3tb-hdd-usb-drive-on-winxp-32bit/ only a nice confirmation with a 8 Tb disk drive. jaclaz