jaclaz

Still, it is the same, usual bull§hit from MS marketing department, that contributes only to confuse users/customers and allow the existence of (highly paid) third party consultants. Four main cases 1) Do you have a server? Go for a Server OS. 2) Do you have a desktop or "full size" laptop? Go for a desktop OS. 3) Do you have a tablet or touch netbook? Go for a tablet OS. 4) Do you have a smartphone? Go for a smartphone OS. The good MS guys tried initially to convey the idea that one single OS was good for #2, #3 and #4, then they removed #4 altogether (and all the related bull§hit, including the "Continuum" experience) and now, while all the rest of the world easily understood that #2 and #3 are NOT the same thing, they insist that #2 and #3 are the same thing, BUT that #2 should be divided in #2a, #2b and #2c .... jaclaz

Well, historically the good MS guys failed at it (after the re-unification with XP), but you seem like more in a conspiracy theory than anything else, there is an official announcement (in late August): https://blogs.windows.com/business/2017/08/10/microsoft-announces-windows-10-pro-workstations/ (which BTW also explains why they are ripping away ReFS from "normal" Windows ) Basically new machines with the "right" kind of processor will be sold with the new "higher end OS", those with same level hardware can buy an upgrade, see: https://www.uk.insight.com/en-gb/shop/microsoft/software/microsoft-windows/microsoft-windows-10-pro In a nutshell it is IMHO not about "Microsoft also would like to stop people from purchasing mis-matched configuration, which is common." but more "How can we extract a few more bucks from either the OEM or the final user in exchange of next to nothing". jaclaz

Why not reading posts before replying? jaclaz

JFYI: Don't try to cry and Try not to cry have very different meaning in English. jaclaz

More than "Spanish", it is the (free) ro (Read Only version), that you can find everywhere, The actual Commercial version was from Winternals (the Commercial company connected with Sysinternals): https://web.archive.org/web/20070526051602/www.sysinternals.com/Utilities/NtfsWindows98.html jaclaz

I do . The grown up cat looks nice . And this constitutes proof that at least one person exists that buys software and does not use it, not even to test it or to make sure - within the return period - that the media actually works, a single data point, I know, but still it is good to know. jaclaz

Just in case, and for no apparent reason, another Apple link: http://images.apple.com/legal/sla/docs/osx_snow_leopard_sec_upd.pdf Point 2.A) might have some relevance: (bolding is mine) jaclaz

I guess because simply noone uses it, and noone has actually delved into the (non-existing or scarce, often outdated and sometimes misleading) documentation. The thingy was once upon a time called ProtogonFS, JFYI: http://reboot.pro/topic/15466-refs-formerly-protogon-in-windows-8-the-new-filesystem/ Relevant (beware, it is signed Sinofsky and likely to contain marketing fluff): https://blogs.msdn.microsoft.com/b8/2012/01/16/building-the-next-generation-file-system-for-windows-refs/ The "Robust disk update strategy" and "Resiliency to disk corruptions" should be the parts of your interest. In a nutshell a modified file is re-written *elsewhere* and checksummed while the original is kept until the checksum is verified. That is fine and dandy (and also "smart") the issues (as I see it) are more connected with the "atomic" (one of the adjectives that MS likes a lot) nature of the file system transactions and with their logging/indexing mechanism. But all in all there is no reason why it should be "worse" than NTFS, the point is more about how much "better" than NTFS it is and whether that amount of betterness is enough to justify its adoption outside the intended, designed, scope (of storage and "Storage Spaces"). jaclaz

Well, if you trust (even slightly and only partially) marketing, you have actual reasons to be not calm . JFYI, from: https://web.archive.org/web/20101127235326/http://support.microsoft.com/kb/2419492 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