jaclaz

Sure , but the point is m00t (with all due respect). It is all about fairness , IMHO people using 8.x do deserve to be nagged by the UAC , the point was only about the current simple implementation that adds the UAC prompt to the poor, innocent XP users, and about having a simple way to have the thingy works as it should (UAC prompt on OS that woud normally require it, NO UAC prompt on OS that would not normally require it) without implementing a Windows OS version detection routine, i.e. finding a simpler solution for that. The queer thing is the behaviour of the command on the USB connected disk, as said before. jaclaz

Well, no. , what is strange is that it seems that there is a sort of "transparent UAC" in the latter On windows XP there is no difference between an eSATA and a USB connected device and the dsfi tool works "normally" on both. From what you report it seems like the stupid Windows 8.x makes a difference (BTW, though I believe that Windows 8.x is very stupid , I didn't thought that it could be this much stupid ) The "Access is denied." when the command is run with the eSATA connected disk is IMHO "normal", you are running the command in a NON elevated command prompt, the stupid UAC intervenes and denies access, this is reported as an ERRORLEVEL of 1 (the command failed). When you run the same command, in the same NON elevated command prompt, the command apparently goes through, i.e. the correct message from dsfi is displayed and the ERRORLEVEL is at 0 level - success - BUT the target disk is NOT changed I can understand how Windows (including XP) may want to distinguish from an "internal" disk (AFAIK an eSATA connected disk is NOT different in any way from a SATA connected disk inside the PC case) and an "external" disk (please read as USB connected) see also: http://reboot.pro/topic/9461-page-file-in-usb-hard-disk/ But I would have expected that the UAC either protects a disk (if "internal" i.e. IDE/SATA/eSATA) or doesn't protect it (if external, i.e. USB), not that how it seems in this latter case it lets the tool write "virtually" (possibly to a cache of some kind and then fails in flushing the cahce to the device). BTW it is not a real issue , in practice we can go back to executing anyway the tool through execute.exe (and thus provoking the unneeded prompt in XP ) or at this point maybe better add to the batch a small OS version detection routine and let it decide, depending on the OS version detected whether to run the command through execute.exe or directly. @dencorso Thanks. I know that I am old-fashioned, but I chose this elevate.exe: http://code.kliu.org/misc/elevate/ over (say) this one: http://jpassing.com/2007/12/08/launch-elevated-processes-from-the-command-line/ because it is 5 kb as opposed to 69 Kb , I fail to see the point in having people downloading and installing 432 KB - 10.9 MB* (or more) of MS bloat jaclaz

This should more or less mean that the hardware (or the driver, or both) is/are capable of finding out that you inserted a USB 2.0 cable in the connection and thus they slow down the negotiation on the Bus (or *whatever*) to USB 2.0 speed. All in all the possibility of the "Ext. HDD's Original USB 3.0 cable" being simply defective (i.e. working fine at USB 2.0 speed BUT failing at USB 3.0 speeds) has not been ruled out. For all we know it is possible that the "Windows 7" (and it's driver(s)) is/are "better" than what Linux uses, in the sense that it is possible that *somehow* the Windows 7 operates at "full" USB 3.0 speed (and the cable prevents it from working properly) while the Ubuntu *somehow* uses a slightly slower transfer/negotiation rate and then succeeds. Or viceversa, it is possible that Ubuntu is "smarter" and, finding that at "full" USB 3.00 speed there are errors in the connection, auto-negotiates a lower speed while the Windows 7 is "dumber" and operates at full speed "or nothing". Maybe the good ol' times are back and the cable is actually the culprit: http://www.msfn.org/board/topic/163189-hard-drive-controller-errors-abound-atapi-event-11/ http://www.msfn.org/board/topic/163189-hard-drive-controller-errors-abound-atapi-event-11/?p=1041690 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