jaclaz

Yep, missing "l" is a typo corrected in the original post. I don't think that Windows 8/8.x manages PhysicalDrives in any way differently from previous OS versions, at least up to Windows 7 dsfo/dsfi has no issues that I know of. Unless there is some kind of issues with UAC, disk protection or *whatever*. Maybe you need to take the disk offline in order to be able to deploy the image to it? http://www.eightforums.com/tutorials/53106-disk-set-offline-online.html In any case, you can deploy the image under XP and then test the result in Windows 8/8.1, the dsfi commands in the Switcher.cmd do not access the \\.\PhysicalDrive, but the (mounted) volume through it's drive letter, and they should not suffer from the same issue. jaclaz

Why anyone would want to use anything but the latest version of 7-zip on a .7z file is a mistery to me, however, get it as .zip. jaclaz dualmode.zip

Ok. Please find attached a test image, it is to create a NTFS volume about 100 Mb in size. You need to extract the image from the archive and then dd it to the target disk. If you don't have already a suitable dd-like tool, get the DSFOK tools from here: http://members.ozemail.com.au/~nulifetv/freezip/freeware/ and run the command: dsfi \\.\Physicaldriven 0 0 dualmode.img where n is the number of the disk as seen in disk manager. (be careful to choose the right n) Disconnect and reconnect the disk. What should happen: opening explorer you should see two added drive letters one of the two will be relative to a (very small) volume 68 Kb in size open this drive and in it there will be (among other files) a Switcher.cmd run it, it will - if needed - switch between 512 bytes/sector and 4096 bytes/sector filesystem for the second volume copy to this second volume a few files disconnect/remove the disk and connect it again through the "other" interface repeat steps #1 to #4 check that the files you wrote in step #5 are still there, normally accessible, etc. use the second volume indifferently though the one or the other interface.Points of note: the disk will remain set to the bytes sector relative to the "last run" of Switcher.cmd, so, when you re-connect it through "the other" you NEED to run the Switcher.cmd again (while if you re-connect it through "the same" it is optional and only useful to verify that the volume was mounted correctly).if you double click on explorer on the second drive letter, if the bytes/sector are set "the other way" you will be prompted to format the drive, DO NOT do it, it simply means that you must run the switcher.cmd.the drive/volume should behave normally in everything, including CHKDSK, but DO NOT use Disk Manager or any other tool to modify the partitioning.Limitations: there can be only two volumes on the disk, one is the pre-made very small volume and one for "all the rest" this setup is intended for a NON-bootable disk, maybe it could be possible to make it bootable, but ONLY through the interface that exposes the device as 512 bytes/sector If the experiment succeeds, I will put together a set of instructions and a batch to the effect of the following: you connect the disk through the USB interface (i.e. the one that exposes the device as 4096 bytes/sector) you create normally from within the Windows a NTFS partition using all your disk space (starting by default from sector 256*4096 or 2048*512 or offset 1,048,576) and format it you run a few commands to "convert" the disk to the "dual mode" settings jaclaz dualmode.7z

Yes and no. The 2.2 Tb limit is in the 32 bit wide field in the MBR but it only applies to 512 bytes sectors. Once you get to 4096 bytes sectors there are no issues up to 8 times that size. NTFS as a filesystem is fully compliant with non-512 bytes sectors, and as as well CHKDSK and FORMAT seem like working fine. The Disk Manager (and possibly the diskpart) may on the other hand have some problems with them and the use of a third party tool (or of another later NT OS) may be needed. As well fsutil will not work fully. As hinted before the issue with BIOS is that most of them are simply badly coded and believe that a device MUST have 512 bytes sectors, once we have removed the BIOS from the equation (as all NT operating systems use a HAL or Hardware Abstraction Layer) the issue may lie in the drivers used by the OS to access the disk. There was a Windows 7 update (that essentially is made out of a bunch of updated disk/port drivers) http://support.microsoft.com/kb/2510009/en-us http://support.microsoft.com/kb/982018/en-us and one for Vista: http://support.microsoft.com/kb/2553708/en-us (but this one is less relevant, as it is mainly about specific ESENT compatibility and an updated fsutil) I guess that we will need to wait and see, right now I believe that some combo hardware+manufacturer drivers have no issues, while other ones may have them (and it is unlikely that the motherboard manufacturer will issue new drivers for XP). jaclaz

Dave-H, are you game to play "lab rat" ? I think I have a workaround for your situation, and even if it is not really *needed* anymore, if it works OK it could be of some use to someone in the same situation. If you are willing to test it, let me know and I will put together *something* that you will be able to test on your device (this will require of course a new partitioning/formatting of the disk). jaclaz

They are TWO separate issues (actually a single issue with two separate possible solutions, both not fully "sound"), let's not mix them together, please. The MBR partition scheme has LBA fields (let's set aside CHS ones that are not used by most modern OS anyway) that are 32bits. This makes any LBA address bigger than 2^32-1=4294967295 become "a suffusion of yellow". LBA address represent sectors or "blocks", on "normal" traditional media where sectors are 512 bytes each, this means that anything bigger than 4294967295*512=2,199,023,255,040 i.e. roughly 2.2 Tb cannot be represented. The "natural" solution to this would have been (and actually was and actually is) to make media with larger sectors, and the hard disk industry decided that the next bigger sector size that was more convenient (for a number of reasons) was 4096 bytes, and so-called AF or advanced Format disk drives were started being manufactured. With the MBR scheme the maximum addressable space becomes 4294967295*4096=17,592,186,040,320 i.e. roughly 17 Tb. The issue here is that a number of BIOSes (actually I believe almost all of them) were and are not compatible with a sector size different from 512 bytes (which rules out larger than 2.2 Tb disks from being a bootable device) and the good MS guys (that could have easily fixed OS support for 4 Kb sectored disk drives) for their own reasons decided to NOT fix the (BTW very little issues) on existing operating systems to have them operate with 4 Kb disks (which are only supported "fully" on 8.x and later). The good disk manufacturers then "invented" the so-called 512e drives, i.e. drives that are actually 4 Kb sectored but that expose themselves as being 512 bytes/sector as a "bridge" solution, and possibly for some "standardization" for mass production, they also started (senselessly) to make AF (i.e. 4 Kb sectored disks) with capacities well below the 2.2 Tb lmit. In the meantime the good MS guys got on the (largely senseless) UEFI/EFI/GPT bandwagon, and still in the meantime SSD's (that rarely exceed 512 Gb in size) became popular/available. Facts: a modern PC will likely use as boot device a SSD that will be smaller than 2.2 Tb, so the MBR and/or BIOS limits do not apply, or at least do not apply yet. any other disk device which is not a boot device can be MBR and as large as 17 Tb, as long as it is 4 Kb sectored. even XP (with some exceptions mainly related to Disk Manager) has no real issues with 4 Kb sectored devices, if they are not used to contain the boot or system partition (i.e. they are used as Data storage, which is what such large disk devices should be used for), the good guys that designed filesystems were smart enough :thumbsup to forecast the need - before or later - to change the size of the sector size.Lies or half-lies you have been told in the last few years: you need GPT (and not MBR) you need UEFI (and not BIOS) there is a limit of 2.2 TB with the MBR scheme, loop to #1 aboveThe reality is that the good MS guys intentionally (most probably to push the EFI/UEFI and consequently GPT, both specifications they however do not fully respect) avoided to provide proper support on the OS side to the initiative of the hard disk manufacturers (which could have been by itself a "good enough" solution to the 2.2 Tb limit) on the other hand the good guys that wrote the EFI/UEFI specifications did their best to prevent the use of GPT disks on BIOS (particularly to make them bootable on BIOS, which is actually perfectly possible, with a few little tricks), the net result being the current mess and misinformation. jaclaz

Be aware that the Vista structure uses hard links, so be very, very careful (this normally is not related to third party software, but if you are going to attempt moving parts of the OS, it may). jaclaz

Another thing to check (though it is more like shooting in the dark ) do they have the same current consumption? One of the "features" of USb devices is power consumption, maybe one has a lower value than the other? Like one beiing - say 100 mA and the ther being - still say - 300 mA? Try running this with both the 8 Gb and the 32 Gb connected and see if you can spot any difference (besides the obvious ones connected to size) : http://www.nirsoft.net/utils/usb_devices_view.html jaclaz

Strictly speaking COA2 needs not to be installed. The issue you are having is probably that it's installer is 16 bit. Can you "install" it to another PC running an earlier OS and then copy to the Vista machine just the coa2.exe and coa2.hlp? Or, alternatively try on the Vista machine to extract the files from the (Wise) installer, using an appropriate tool *like* WUN.EXE?: http://www.911cd.net/forums//index.php?showtopic=14906 https://web.archive.org/web/*/http://www.reatogo.de/sample/test-WUN.zip https://web.archive.org/web/20060915000000*/http://www.pediy.com/tools/unpack/Wise/WUN.rar jaclaz

Well, it's the first time I hear that a USB stick can be detected as CD/DVD (unless it is set to be one on one or both it's LUN's, or it is a stupid U3 stick) jaclaz

Interesting And scary/queer. Three questions: Are both the 32 Gb and the 8 Gb set as "Removable" (or as "Fixed")? (or are they differently set?) Are both the 32 Gb and the 8 Gb partitioned (or "superfloppy")? (or are they differently set?) Have you tried making a smaller than 8 Gb partition on the 32 Gb stick? (if it is partitioned)jaclaz

Good to have contributed to another happy bunny: http://www.msfn.org/board/topic/128727-cant-access-repair-my-pc-option-via-f8-startup/?p=828512 Well, with all due respect to your opinion, you have to understand how nlite is an "advanced" but "generic" tweaking/reducing/whatever tool, while people may have every kind of *needs* or *wishes* making them all happy through nlite would have further complicated the tool, the interface would have become more like a spreadsheet than anything else as you would have hundreds or thousands of possible chioices/settings. jaclaz

By any chance do you also find the ribbon interface of post 2003 MS Office to be "better" and more productive? jaclaz

I would still be curious to know how the disk is seen in Windows 8.x when directly connected to a SATA port. According to the mentioned resources: AF, 4K native -> 4096/4096 AF, 512e -> 512/4096 512n -> 512/512 The results of the previous tests seem to indicate that the adapter translates also the SATA channel so that what gets in is 512/4096 and what gets out is 512/512 on eSATA and 4096/4096 on USB. While Dencorso and NoelC were happily lingering in their consumerist laziness I did a few checks and, though I have not yet nothing of practical use, I can confirm that with a few byte patches it is possible to have the same NTFS filesystem mounted fine on either 512 or 4096 bytes sectored device, as a matter of fact I was surprised by the support (for access NOT booting) that good ol' Windows XP has for NTFS on 4kb sectored (virtual) devices, something that the good MS guys seemed to exclude a priori. jaclaz

Good mooorning , Mr. de La Palice: http://en.wikipedia.org/wiki/Jacques_de_La_Palice Sure , guess WHY newer version of Isobuster have this feature/WHO asked for it to its Author? http://www.msfn.org/board/topic/172655-strange-or-odd-multi-or-single-boot-cddvd-el-torito-images/ And - at least for these Acronis .iso's - the little batch here: http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/ http://reboot.pro/topic/20004-boot-a-acronis-true-image-2014-iso-image-with-grub2-at-uefi/?p=189345 adds the possibility of using iso-hybrid booting with GRUB2. jaclaz

I would think that the initially given resource: http://www.msfn.org/board/topic/172917-integrating-patched-system-files-without-wfp-problems/ is simple enough, now that it also contains a practical example, detailed verbally AND in Hex / gsar syntax http://www.msfn.org/board/topic/172917-integrating-patched-system-files-without-wfp-problems/?p=1089478 What is the issue you are having with it? Your mission, should you accept it, is to change in those lines: %P to \(00) or, if you prefer (in a Hex editor): 25005000 to 5C000000 Then (this is what I am not too sure about ) you need to recreate the checksum of sfcfiles.dll, or at least this is what ElTorqiro suggested: http://www.msfn.org/board/topic/98306-wfp-app-for-removing-individual-files-from-monitoring/ ModifyPE: http://unattended.msfn.org/unattended.xp/view/web/16/#modpe though nowadays pechecksum is advised: http://www.msfn.org/board/topic/171814-posready-2009-updates-ported-to-windows-xp-sp3-enu/page-3#entry1078428 jaclaz

You don't "open" a binary file with readable text (particularly as this .dll uses mainly Unicode for the characters). But you may "peek" in it by extracting strings from it, like you know: http://www.mcafee.com/it/downloads/free-tools/bintext.aspx Still you will need a hex editor (or a hex capable patcher like the mentioned on the other thread gsar) to edit the file. And then you will need to re-create the checksum, if I recall correctly. jaclaz

Hmmm: http://www.msfn.org/board/topic/33081-remove-wfp-on-a-per-filedir-bases-wfp-still-on/ jaclaz

There are two kinds of possible "issues". the BIOS (and consequently the DOS) may not be able to "see" the SATA disk connected through the card the Windows 9x/Me (please read the underlying DOS) CANNOT boot from *anything* but active partition of first disk So, if the BIOS can overcome the #1, it is possible that you will need *something else* (like grub4dos) to remap drives in order to evercome the #2 or you will need to have anyway the DOS boot from the internal disk and have the Windows 9x/Me installed to another volume (on the SATA card connected device). jaclaz

You mean *like* removing the related files from SFC/WFP? Here: http://www.msfn.org/board/topic/172917-integrating-patched-system-files-without-wfp-problems/ jaclaz

It is possible (but highly unlikely) that there is available the "Manufacturer Tool" to change the behaviour of the controller of the enclosure. Still, what is unresolved is why that particular disk behaves in fsutil as 512n IF it is an AF drive (evidently of the 512e type). Dave-H, which EXACT disk was in the enclosure before? what is the make/model of the enclosure? With all due respect to all the people that suggested buying another disk, buying another external enclosure (or both) or changing the backup strategy/whatever, those are not solutions, nor workarounds to the actual specific issue, the suggestions are good and sound of course , but heck, the fun is (or should be) in finding out what exactly happens and have that specific hardware work, one way or the other. @shae I don't think that you can get that info on XP, the "feature" has been added to Windows 7 first (it is in the actual driver(s)) and actually a specific update may be needed, see : http://www.symantec.com/business/support/index?page=content&id=TECH194586 http://support.microsoft.com/kb/982018/en-us And (JFYI) this has some connections to the matter, it is a mess : http://www.forensicfocus.com/Forums/viewtopic/t=11431/ jaclaz

Try using google image search. jaclaz

I stand corrected. I don't know. What Dave-H got was (eSATA) which is the behaviour of 512n or 512 native" : What he got (USB): How an AF (512e) drive should be detected: http://msdn.microsoft.com/en-us/library/windows/desktop/hh848035(v=vs.85).aspx So the jumper is to emulate the 4096 Bytes Per Physical Sector? I have believed till now that the AF format drives were "native" 4096 Kb and that in the case of 512e the emulation was "downwards", is it possible that the good WD guys have a "full" 512 bytes emulation? jaclaz

Interesting opinion , I like it! jaclaz

I tend to call that "common sense" : , but yes, it is not-so-common. jaclaz