jaclaz

Not insinuating anything, I am plainly stating that (IMHO) the *need* for a multiple display is a "niche", related to: graphical design (very high level one) and that counts for two fingers of my left hand, namely thumb and index CAD/CAM (also rather highish level) and that counts for middle, ring and pinky software engineering (because you tell me so )Personally I cannot even think to work on a graphic/CAD workstation (let's say with Autocad or Bentley Microstation) without a pen/tablet input device, and two monitors, one as work display and one for menus, but still 90 to 95% of people I know that use this kind of stuff at a more than elementary level use a plain single monitor and even a common mouse and however personally it is what? 10 years or so that I don't use seriously Autocad or Microstation. Admittedly, it is very possible that I know personally only very few people and that the few I know are among the ones with less resources and - just like myself - very cheap , but still I believe that it is rather UNcommon to find people that have (let alone *need*) a multiple monitor setup at work. Not at all. The (little) engineering I do is related to buildings/constructions. When it comes to software what I do - at the most - are half-@§§ed batches/simple scripts, nothing that cannot be done without too much hassle on - say - a 800x600 display or that I can do VERY comfortably on a 22" monitor at 1680x1050 (which is what I actually use daily). jaclaz

And - just to show how old (and old fashioned ) I am - you will have to pry my HP 28C calculator from my cold hands... The possibility (offered by HP and Olivetti - but not (say) Panasonic - calculators and by a good ol' IBM "M" keyboard) of pressing a key and KNOW for SURE that you have pressed it without looking at the screen makes to me a lot, really a LOT of difference. Clickity, clickity, click.... jaclaz

Good I am still thinking about problems that this overlapping may cause and evaluating simplicity against "features"/limitations. I have put together a few working schemes, one with both the FAT12 and the NTFS volumes inside extended, one with the FAT 12 primary and the NTFS volume inside extended (on both 512 and 4096 geometries), one where the FAT12 is "fixed", primary and the NTFS one is also a primary and it's MBR entry is rewritten at each switch (more "classical") The first one, on one hand is more elegant as it occupies only one entry in the MBR and this entry in the MBR needs not to be modified once the "base image" is deployed, the second is "better" though it will "waste" more bytes (unusable) for the FAT12, BUT both will have a mismatch in Extended partition size, the third has the disadvantage of requiring to correct both the MBR and the VBR of the NTFS partition at each switch (something - rewriting the MBR partition table at each switch - that I would prefer to avoid, and it has to be seen if doable at all if the switcher.cmd is run from within the FAT12 volume). So, possibly the "right" solution is the second one, the limits would be that two entries in the MBR are occupied, but it would allow, at least when connected through a 512 bytes/sector interface, to boot from the device, which is IMHO a definite plus. jaclaz

Well, maybe for not-so-important things a single display is enough. I am able to count people I know with a multi-monitor setup (that actually *need* it) on the fingers of my left hand, I wouldn't rate this as something "common" or "widely used" (let alone "largely needed"). jaclaz

Very good. Just to avoid this becoming a myth of some kind the commands: F3 T>m0,2,2,0,0,0,0,22 and: F3 T>m0,2,2,,,,,22 (no zeroes) are EXACTLY the same. With the 0's it is the "explicit" form (and is more readable/easier to type correctly), without it works exactly the same as the 0's are implied. jaclaz

DSYNCHRONIZE http://dimio.altervista.org/eng/ 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