jaclaz

Hmmm. @ECHO OFFSETLOCAL ENABLEEXTENSIONSSET yes="ja"SET yesCALL :check %yes%GOTO :EOF:checkECHO This is check, %1 without quotes is %~1 and inside quotes is "%~1" jaclaz

Then, this should work nicely (still in 8.x, NOT elevated command prompt): dsfi \\.\I: 0 0 as512.bss || elevate.exe -c -w dsfi \\.\I: 0 0 as512.bssas well as on XP (on 8.x the command should be run through the elevate.exe and thus prompt for UAC elevation, on XP directly). jaclaz

It's queer. Did you try it in Windows 8.x from an open command prompt NOT in elevated mode (and on the eSATA connection)? It should have got you a failure of some kind jaclaz

The reference you miss on "a suffusion of yellow", meet Dirk Gently's holistic calculator: http://www.thateden.co.uk/dirk/ jaclaz

Good , now that we have a "working prototype", we need to find a way to reproduce on *any* disk. The sample image I posted was "hand made" and uses a trick (or two) that make it not really-really "kosher", to save myself some strange calculations I removed part of the boot code of the NTFS volume and used it's bootsector as both bootsector and EPBR. I am thinking about the best way to have the thingy (besides working) also as "compatible" as possible with the various "queer" (or in some cases plainly "stupid" limitations/conventions of the various OS's). Since we are anyway talking of at least a 1 Tb drive, I guess it is not an issue if we waste a handful of megabytes, in order to make the (now 68k) small partition a bit larger. (there are some constraints that may cause a few megabytes "wasted") The NTFS volume NEEDS to be formatted when the disk is mounted "as 4096 bytes/sector", but I am not yet convinced of the procedure to have the stupid disk manager (or the stupid diskpart) to do the exact things I need. Most probably it will be needed to create the NTFS partition as primary after a "dummy" temporary partition and then convert it to logical volume inside extended I still need to know what happens with the errorlevel of dsfi under windows 8.1, please. jaclaz

Yep jaclaz

It's queer. The testdisk log through USB 2.0 is "normal" (initial part). The testdisk log under USB 3.x is not: If we set aside (temporarily) the partition that is shown as RAW under USB 2.0, the logs seem like there is a connection issue under USB 3.0. That could be the actual USB port/controller on the PC (or the Windows 7 driver) or the interface/bridge on the hard disk case or the cable not supporting USB 3.0 data flow. Since you have no issues with Ubuntu, most of the above seem however unlikely. and it *must* be the Windows 7 or the actual driver used in it. It is possible that Testdisk and the Windows 7 (or the USB 3.0 driver) have issues in communicating, but since you have the same issues in the "plain" Windows 7 the most likely culprit is the interface/controller driver (possibly combined with the specific SATA to USB bridge inside the hd case). Which specific driver are you using? Which specific USB 3.0 controller does your motherboard have? As a check, can you try examining the disk using DMDE? http://dmde.com/ there is a Windows (GUI) version, which is the one I normally use, but there there are also a Windows CLI and a Linux CLI ones, so that you can compare results under the two OS. jaclaz

Well, usually 1/10th of the time is used to write the batch and the remaining 8/10th's are used to prevent the user from entering nonsense. Before you ask, the 1/10th missing in the above is wasted in looking at squirrels or similar. jaclaz

Hmmm. What about: :ntbset /p brand=Manufacturer's name: if "%brand%"=="" echo.&echo. No input. Try again.&goto :ntbgoto :startjaclaz

Well, you have to untick the checkbox "Protect my computer ..." Heck, we are doing dangerous things here , you need to provide your explicit consensus . jaclaz

Sure you are missing the chance of occupying without any need some hard disk space. Basically four cases : If you run a 32 bit "full" system you need the 32 bit version ONLY If you run a 64 bit "full" system complete of the WOW64 32 bit subsystem, you need the 32 bit version ONLY as the 64 bit version would not give you any advantage besides the increased disk occupation. if you run a 64 bit "advanced" PE with the WOW64 32 bit subsystem added, you need the 32 bit version ONLY AND another 32 bit PE with the 32 bit version for use on machines that won't boot from a 64 bit PE if you run a 64 bit "default" PE without the WOW64 32 bit subsystem, you need the 64 bit version AND another 32 bit PE with the 32 bit version for use on machines that won't boot from a 64 bit PEOf course case #4 will also prevent you from running a large number of useful other tools that (rightfully) do not exist in a 64 bit version, so it is the least smart choice/possibility. jaclaz

Well, this is due to elevate.exe having been compiled with minimum OS version 6. Try using the attached (edited) version. Change that part of the batch to: IF "YES"=="%Confirm%" (elevate.exe -c -w dsfi \\.\%SecondDriveLetter% 0 0 %Source%GOTO :Check) The good thing with this approach is that a popup needing a confirmation by the user appears in XP as well. All in all and at the end of the day checking the OS version may be still better, but this allows for an added possibility to cancel. Can you please in the Windows 8.x try running this as batch (make sure that I: is the right drive letter or change according to your current drive lettering): dsfi \\.\I: 0 0 as512.bssECHO Errorlevel is %ERRORLEVEL% and report the output? jaclaz elevateXP.zip

BUT you can also remove altogether the condition: if exist d:\win7\boot\cs-cz\nul ( set language=cz copy e:\unattended\AeroNoBackground-cz.theme d:\win7\sources\$OEM$\$$\resources\themes\AeroNoBackground.theme ) else ( set language= copy e:\unattended\AeroNoBackground.theme d:\win7\sources\$OEM$\$$\resources\themes ) jaclaz

Hmmm. Run Testdisk with a LOG, twice (one when connected through the USB 2.0 and once when connected tthrough the USB 3.0). Compress the logs into a .zip archive and attach the archive. Could it be that the issue is *somehow* connected with this recent - in the works - one? http://www.msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ jaclaz

Good, but the elevate.exe run under XP will throw an error. I need your feedback on the behaviour of the command. Try reverting the check. IF "YES"=="%Confirm%" (elevate.exe -c -w dsfi \\.\%SecondDriveLetter% 0 0 %Source%IF %ERRORLEVEL% equ 0 GOTO :Checkdsfi \\.\%SecondDriveLetter% 0 0 %Source%GOTO :check)this will attempt to run dsfi through elevate.exe and if the OS is not Vista or later it will attempt running it directly. I could add an OS version detection routine of course, but if we get to have the batch working this way it will be simpler. jaclaz

Well, not too hidden, like: http://sourceforge.net/p/regshot/support-requests/2/ http://www.wincert.net/forum/files/file/16-regshot2-unicode/ Though you need to be logged in on wincert to download files, so better get it through portableapps: not here: http://www.portablefreeware.com/?id=297 but here, of course: http://www.portablefreeware.com/index.php?id=2505 jaclaz

Well, if it works directly inside an elevated command prompt then it should work exactly the same when run through elevate.exe. Maybe it is the "mixed mode" that is the issue? dsfi is 32 bit. Try using the 32 bit elevate.exe, and try also from a non-elevated command prompt to run (it is well possible that the modified batch code isn't doing what I expected it to do, I have no way to test it directly): elevate.exe -c -w dsfi \\.\I: 0 0 as512.bss And/or try running this as a batch: dsfi \\.\I: 0 0 as512.bssECHO Errolevel is %ERRORLEVEL%maybe the Errorlevel is not set/parsed correctly? jaclaz

Making a new post so that Dave-H has more chances to notice it (as opposed to editing previous one). Ok. Get this: http://code.kliu.org/misc/elevate/ extract the elevate.exe from \elevate-1.3.0-redist.7z\bin.x86-32\ and copy it to the "J:" drive (the very small FAT12 drive). Edit the Switcher.cmd as follows: Near the beginning change (add a line): Near the end, change this: to: jaclaz

Good . So it is just a matter of detecting if the OS needs Admin privileges to run the dsfi command, and if they are needed, *somehow* elevate the privileges. I am not at all familiar with that UAC nonsense, but I'll have a look around, surely a suitable solution exists . jaclaz

Doesn't Regshot run on Windows 8.x? http://sourceforge.net/projects/regshot/ jaclaz

Good. So the issue here seems to be that either Windows 8.x *somehow* locks the volume or that the dsfi.exe command does not work in Windows 8.x (and this could be due to other reasons), or maybe there is the need to run them as Administrator because the command is UAC (or *whatever*) protected? Can you try using another dd-like tool? The general idea behind the batch is to overwrite first 4096 bytes of the second volume, which is on \\PhysicalDriven at LBA 2048) when mounted on a 512 bytes/sector) or at LBA 256 (when mounted on a 4096 bytes/sector) and is in both cases sector 0 of the \\.\LogicalDrive or aboslute offset in bytes 1048576 with either of: as512.bss <- if the disk is seen as 512 bytes/sector as4kb.bss <- if the disk is seen as 4096 bytes sector So, for the tests, if you make a folder on your "main" drive, say C:\mytemptest and copy to it those two files, you can try the following commands: on eSATA (where the disk is seen as 512) dsfi \\.\<drive letter> 0 0 as512.bss on USB (where the disk is seen as 4096) dsfi \\.\<drive letter> 0 0 as4kb.bss The above are the actual commands that the batch attempts to execute and should give you the same "access denied" error, but try them from a command prompt in "elevated" mode, maybe that is the issue. Alternative commands are: on eSATA (where the disk is seen as 512) dsfi \\.\Physicaldriven 1048576 0 as512.bss on USB (where the disk is seen as 4096) dsfi \\.\Physicaldriven 0 1048576 as4kb.bss Or try with dd for windows: http://www.chrysocome.net/dd the syntax will be: on eSATA (where the disk is seen as 512) dd if=c:\temptest\as512.bss of=\\.\<drive letter> bs=512 dd if=c:\temptest\as512.bss of=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} bs=512 <- use dd --list or mountvol to get the Volume x's dd if=c:\temptest\as512.bss of=\\?\Device\Harddiskm\Partition1 bs=512 <- use dd --list or to get the m, n on USB (where the disk is seen as 4096) dd if=c:\temptest\as4kb.bss of=\\.\<drive letter> bs=4096 dd if=c:\temptest\as4kb.bss of=\\.\Volume{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx} bs=4096 <- use dd --list or mountvol to get the Volume x's dd if=c:\temptest\as4kb.bss of=\\?\Device\Harddiskm\Partition1 bs=4096 <- use dd --list or to get the m, n jaclaz

Generally speaking, yes, as a matter of fact I said "to/from", though as said it is not most probably the issue at hand. Each and every OS executable file compiled for 64 bit will be a bit larger than the corresponding one for 32 bit, or, if you prefer, the typical 32 bit install requirement is within 16 Gb, whilst the 64 bit will be around 20 Gb. jaclaz

You are trying to do too many things at once, following not the given procedure. Run the batch. If you are asked to type YES, type YES. If you type "yes", the batch will do NOTHING. You were asked to type "YES" (not "yes"). Try running the batch again. Type YES if prompted Then try running it again (the idea is that the batch can be run as many times as you want and if the volume is already with the "right" geometry it will confirm it, while if it is not it will prompt you to switch to the "other" geometry. It is possible that Windows 8.x (for it's own reasons) would not automatically assign a drive letter to the first or the second partition (or both), at least the first time that the disk is connected hence: jaclaz

More probably 8 Gb are needed. The "switch" with 4Gb or 6Gb does not make much sense (as I see it) consider also how in any case a 64 bit OS needs to transfer more data from/to the hard disk, though with SATA speedish disk this should not affect noticeably performance. jaclaz

Try again on the XP. Re-deploy the image under XP. What happens when you run the switcher.cmd? Which output do you get? On windows 8.x: What happens when you run the mountvol command? The Switcher.cmd is made with the scope to be run exclusively from the smallish volume that should be *always* mounted and always have a drive letter assigned, if this is not the case, try assigning a drive letter manually with mountvol or in the disk manager. jaclaz