jaclaz

So, the 2048 geometry is automagically generated by an original MS (or AMD) driver (though in a couple specific versions only), right? The results of your (nice ) experiments mean in a nutshell that it is possible to "overrule" an exposed device geometry through a driver, I actually suspected something like that since the time the VSS virtual disk driver was found: http://reboot.pro/topic/6492-virtual-storage-driver/ (that driver allows to create virtual disks with either a 512 or 4096 sector size) but I thought that the feature was possible only because of the "virtual" nature of the (simulated) hardware. It should also mean that the good MS (or AMD) guys decided to keep this piece of info for themselves, most probably choosing the easier (please read as lazier) approach that would not create compatibility issues, which might be a "reasonable" choice for external devices (USB disks) that by definition are removable/exchangeable but that sounds like being overcautious for an internal device. jaclaz

Yep, I can confirm vcopy (actually Verbatim copy, I knew it with this more descriptive name) is a very nice tool, useful in a number of situations. As a side note - talking of copying files in a "proper" way - there is - generically speaking - a lack of tools capable of dealing with "sparse" files, or at least they are not easily findable. just in case I put together some of them (which I found "here and there" ) in a post on reboot.pro, here: http://reboot.pro/topic/20487-any-tut-on-expanding-c-partition-on-many-ramdisk/?p=192898 jaclaz

Good to know. And good to know that someone else (as compared with): http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml made the "right" thing, which is that of being able to open a command prompt in the current directory, compatible with the (stupid BTW) elevation of newer NT systems. jaclaz

Yes and no (about bootability/readability). Bootable it won't be (in BIOS), the issue here is - besides the sector data "sensed" (and *somehow* translated to 2048 bytes) that the actual MBR code is "hardcoded" to 512 bytes/sector and will simply fail. (which does not mean that it is possible - in theory - to write a specific/special MBR code, but IF - as it seems - the magic translation is in one of the Windows drivers, it has to be seen - at BIOS level - which sector size is actually seen). Later (when you will have made all the experiments in "non bootable" mode) we can see what happens at BIOS level using grub4dos. Readability in Linux might instead be possible, the MBR - as said and as seen in various experiments with 4096 bytes sectored disks - is "sector size agnostic" (or - if you prefer - there is no field anywhere to specify the sector size at MBR level and 512 bytes is assumed by everyone) BUT the filesystem (be it NTFS or not) has a field for sector size, so at that level it is well possible to have a non-512 bytes/sector perfectly readable, in the end it depends whether the Linux NTFS (or other filesystem) driver: 1) is written "properly" and takes the sector size field into account 2) can (the actual OS) mount the volume as "superfloppy" (i.e. bypassing the MBR, mounting the partition/volume only) In a similar (but actually completely different) situation I devised a (half-@§§ed but working) special formatting scheme allowing to "switch" a same disk between 512 and 4096 bytes sector, the case was an external case with both a USB and an e-sata connection where one of the interface exposed one sector size and the other the other, here: The same approach (if only condition #1 above is fulfilled) could be adapted to this case (and it should/could work both under Linux and on other NT based OS, though unfortunately most probably not under XP if the volume is over the same classic 2.2 TB "limit"). jaclaz

To be fair, Dibya never said Christmas of which year ... jaclaz

Yes, some BIOSes (particularly those of nootebooks/netbooks) have not such an option, you are locked into an UEFI only system. Which wouldn't be in itself such a bad thing IF the "standard" actually was "sane" (it isn't) AND IF it was in itself backwards compatible with BIOS (again it isn't). Maybe however (it depends on a number of factors) it could be possible to make the actual Paragon CD/DVD UEFI bootable, but cannot really say. jaclaz

It depends on a number of factors, as said there are several ways to use Ghost and some values - notwithstanding the use of the word "clone" - may not be the same on the "copy". As an example only (i.e. not necessarily what happened in your case) by definition there cannot be at the same time on a same Windows NT system two disk drives connected with the same Disk SIgnature, if - for any reason - this happens, the NT OS will immediately (and silently) changes one of the two to a new value. If *anything* in the boot process relies on such data, the disk drive won't ever boot until either the Disk Signature is reverted to the original value or the *whatever* is updated to reflect the new Disk Signature. But - back to the issue at hand - generically you had a 0XC000000e error coming in the early stage of booting from BOOTMGR. The problem very likely comes from some of the settings in the \boot\BCD. So the "usual" recommended fix is to run bootrec.exe with the switch /rebuildbcd, but the bootrec.exe is only available (normally) on the install CD/DVD or in the WinRE (the Recovery Environment that may - or may not - have been installed on a given machine). But - besides bootrec - there are other tools that can be used, namely: 1) bcdboot 2) bcdedit the above are included in a "normal" Windows OS, and - actually recommended : 3) BootIce a freeware third party tool that is GUI and is easier to use than the previous two: http://reboot.pro/topic/21956-bootice-v1332/ that can - besides editing an existing BCD or creating a new one - also allow to "fix" other possible issues (such as MBR or PBR missinf/corrupted, change active partition, et similia) Anyway all three need a minimal amount of knowledge on the way the BCD is structured. If you look on youtube there are a few tutorials for how to use bootice in these (and other) cases. jaclaz

Well, you need first a primer on how (since Vista) a NT system boots, and the further changes in 7. In Windows 7 the normal setup creates two partitions (both in MBR and GPT style disks): 1) the "system reserved" one, that is active and gets NOT a drive letter when the system is booted <- this one is called "System" by Microsoft and "Boot" by everyone else 2) the "normal" one containing the actual Operting System <- this one is called "Boot" by Microsoft and "System" by everyone else See: http://www.multibooters.co.uk/system.html http://www.multibooters.co.uk/articles/windows_seven.html The "system reserved" partition in a MBR style disk is marked "active" and contains only: 1) the BOOTMGR 2) the \boot\BCD file 3) some other (mostly language files) Allow me to doubt that you had at any moment two partitions active, as this is - besides not allowed - almost impossible to obtain with *any* "Normal" tool To recap: 1) the "System reserved" partition needs to be active AND it must contain the file \BOOTMGR and the \boot\BCD You can via disk manager or disk part assign temporarily a letter to it (when it is attached via USB to the other Windows 7 machine) in order ot check the contents of the (cloned) System Reserved partition. or you can "flatten" the clone by simply copying to the root of the "normal" partition the contents of the "System Reserved" one, and make this latter partition active (this way you will have a "single partition install", not much different from a typical good ol' XP one. Then it will either work or provide a different (hiigher level) error (like the 0XC000000e you mentioned that comes from \BOOTMGR or \boot\BCD), right now the "bootmgr is missing" comes from the bootsector/PBR of the *whatever* partition is active. jaclaz

Well, AFAICR Ghost has more possible settings/parameters than stars in the sky, so you should post which ones you currently use (that fail) and also some details on how (EXACTLY) the windows 7 system you want to "clone" is configured (like Bios/Uefi, reserved partition or not, which bootmanager - if not BOOTMGR - is involved, etc., etc.). jaclaz

Maybe a BIOS vs. UEFI issue? If you are running windows 10 you are probably also using an UEFI system and all the (BTW stupid) complications connected to it, whilst the CD/DVD may be suitable to boot only on Bios (or CSM in UEFI). jaclaz

Good. The mbr is fine. In the MBR the partition entry is (lba) 63-2441879937, and the 2441879937=0x918C2181 is compatible with the "number sectors" of 0x918C2180 that is in the output of "fsutil fsinfo ntfsinfo" (the excess sector is the $BootMirr which is inside the partition but outside the volume). Now, 5 TB are roughly 5,000,000,000,000 which divided by (2441879937+63)=2,441,880,000 makes 2047,60 which is evidently 2048 bytes/sector (and there may be a few excess sectors after the partition, so it is not possible to calculate exactly the capacity from these data) . About the "fsutil fsinfo ntfsinfo" it has been modified in later OS version (I seem to remember from 7) to display some slightly different info, if you can you could try a later version that has the distinction between physical sectors and logical sectors, *like*: https://docs.microsoft.com/en-us/windows/win32/w8cookbook/advanced-format--4k--disk-compatibility-update You could run ntfsinfo by sysinternals (don't worry the 32 bit version runs on XP just fine): https://docs.microsoft.com/en-us/sysinternals/downloads/ntfsinfo so at least we'll have the data directly in decimal. So that disk seemingly exposes 2048 bytes per sector (but it cannot be the disk if the same disk on another PC doesn't), so it must be something in the drivers on that specific OS instance/install , but I wonder what could cause that. I mean, if you installed some "special" tool and you cannot remember, it must still be there and it should be possible to find it (but it would be queer that it is the "intended effect" of a "special tool", as by now, half the internet would be talking about it) so it is maybe a "side effect" of "something" (yes, not a very accurate definition I know) . jaclaz

"fsutil fsinfo ntfsinfo" And you posted everything BUT the output of that command. 2048 or 1024 make no sense (talking of sector size) maybe what you got is another piece of data, size of cluster, not size of sector or maybe something else?. Besides posting the actual output of that command, post the partition table of that disk, that is the easiest way to check the data. jaclaz

Only for the record (since the given link is also for CMD.EXE and 2K/XP), ALL those are - if not "wrong" - "inferior" to this nice shell extension: http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml jaclaz

Yes, that kind, actually the common ones are coloured, example: https://www.startech.com/eu/Cables/Serial-Parallel-PS-2/PS-2-Cables/6in-PS2-Keyboard-Mouse-Splitter-Cable-Adapter~KYC1MF Green by convention is mouse, purple by convention is keyboard. The issue is that they may (or may not) work on a given motherboard. , it depends on the specific way it was cabled, see: https://en.wikipedia.org/wiki/PS/2_port the port on the motherboard may be cabled/designed for "dual PS/2" or for "normal, single PS/2" no way to know, and - to further complicate the matter - I believe that even splitters are not all the same. jaclaz

Semi-random idea, but if Ps/2 works fine, have you tried IF (no guarantee) a Ps/2 mouse/keyboard splitter works? jaclaz

Good. Though to me it is already a miracle that the dropbox location actually allowed you to get up to that point. But your first point was valid, I don't think anyone else ever had this specific issue, as I never heard of anyone attempting to use files in a dropbox storage for this kind of use. jaclaz

Noone said the contrary of that. Just in case: https://www.robvanderwoude.com/redirection.php jaclaz

I see , it is a really old model (but SLC) that has no support for trim in the internal processor/controller. Yes, you can't do more than what WinClient5270 suggested, but it is included among the models supported by the: https://downloadcenter.intel.com/download/29205/Intel-Solid-State-Drive-Toolbox cdob pointed you too, so maybe it is worth the time to check what it can do. jaclaz

I prefer "accurate". jaclaz

You mean late-observant of course, if you were un-observant, you wouldn't have noticed ... jaclaz

That error - basically - means that the BCD is "in use". No way to know from a distance WHAT is using it and keeping it "locked". Try again after a fresh reboot. If it still doesn't work, it should mean that you have *something* (it could be an antivirus, another "security" program, *whatever*) locks it at boot or when you run the WinntSetupFromUSB. If this is the case (and even if it isn't, you can get unlocker: http://www.emptyloop.com/unlocker/ and hopefully_ 1) understand what program/process locks it 2) unlock it manually jaclaz

Good. Due to the way the files are made by the program, new additions (players) will be added at the end of the batters and pitchers files, thus the index/address file will become again not-sequential (even if only in the last part), and you will need - before or later - to re-run the scripts to re-compact it. jaclaz

@MrMADRYAN Post the specific make/model of this SSD. jaclaz

Hmmm. https://web.archive.org/web/20181225133300/https://msfn.org/board/ <- No dice https://web.archive.org/web/20171225070707/http://www.msfn.org:80/board <- No dice https://web.archive.org/web/20161228040343/http://www.msfn.org:80/board/ <- No dice https://web.archive.org/web/20151221233156/http://www.msfn.org:80/board <- Here it is in all its beauty jaclaz

Well you can trim on Vista just fine (manually), if it is possible on XP, it should be also on Vista: The point might be is wherther the specific SSD is "recognized" by available software. jaclaz