jaclaz

The /fw switch is shorthand for firmware, but what is not said anywhere is that they intend UEFI, and not BIOS (though it may work for UEFI in CMS mode ) it is very likely that it was introduced post Windows 7. You just run: shutdown /? to list the available switches to the command. Should be like this (no /fw switch present): https://www.computerperformance.co.uk/windows-7/shutdown-command/ jaclaz

@Dixel I think you are confusing matters: 1) how to batch rename files 2) how to open a command prompt when in an explorer window in the shown directory/folder To batch rename files (#1 in the above list) there are of course working command lines and/or you can write a dedicated batch, BUT there are a number of dedicated third party tools with more (or easier, or enhanced) features. My remark and suggestions were ONLY and EXCLUSIVELY about how to open a command prompt in an explore window (#2 in the above list). For that (open a command prompt in an explorer window, #2 in the above list) there is NO available function in Windows XP, there is something similar (and I later posted a link to an article on petri.com about how to use the existing feature) that however opens a command prompt in a selected directory, NOT in the currently displayed one. To do the latter (open a command prompt in an explorer windows in the currently displayed directory) there is the need for a third party tool, and I posted a link to two of them, one tested and used successfully by me for over 10 years, and another one, not tested by me, but said to be working just fine, more suitable to later versions of windows. jaclaz

@AstroSkipper Take it easy. Using another tool instead of Explorer (like you do with Total Commander) is of course perfectly fine, I only posted a reference to a tool that is useful when running Explorer, working "correctly" unlike the very common suggested workarounds, like these ones: https://petri.com/add_command_prompt_here_shortcut_to_windows_explorer/ that are described as "command prompt here" while they are actually "command prompt in the selected directory". jaclaz

But on Vista you probably want one that is compatible with UAC (not tested by me): http://code.kliu.org/cmdopen/ jaclaz

That difference is likely the one between Gb and Gb: https://en.wikipedia.org/wiki/Gibibyte#Multiple-byte_units Disks sizes are usually calculated with the 1000 multiplier, while MS uses the "real" 1024 multiplier, (roughly) a disk 500GB is seen as 465 Gib and a 512 GB as 475 GiB, the exact numbers depend on the specific disk. jaclaz

In Windows XP you need a dedicated tool (shell extension), the one that works (I am running it since many years) is this one: Background Command: http://www.roggel.com/NGNeer/BackgroundCMD/index.shtml It provides a proper "command prompt here" (unlike other "solutions" that offer "command prompt in the selected directory"). jaclaz

So, if I get this right, for the next 14 years, ME users are fine? jaclaz

Just in case, some details/explanation of IFEO: https://www.dedoimedo.com/computers/windows-ifeo-debugger-gwx-more.html jaclaz

LBA48 has nothing to do with that. Before LBA 48 (which came with ATA-6 in 2002) the method in use was LBA 28 that did not allow to address more than 128Gib/137 GB. (2^28-1)*512=137,438,952,960 Anything that can address more than that has LBA48 alright. jaclaz

I don't understand. There aren't (AFAIK) any problems, the (serious) bug is in XP (and presumably earlier) Disk Manager. We can put it this way: 1) when the XP disk manager was created/programmed the ONLY convention for disk aligment in use (according to the usual MS arrogant paradigm of "all is mine") was to head/cylinder, for *some reason* the tool was coded with the assumption that it would only deal with disks partitioned and formatted along that convention (and by MS tools) 2) when the Vista disk manager was created/programmed they introduced the new MB convention, but since 99.99% of the systems already in use had the old one, presumably they tested the new disk manager with both the existing common situation of millions of disks and with the new convention they had just introduced Historically, third party tools for DOS or Windows tended (understandably) to work similar to the way the Microsoft tools worked, so I wouldn't be surprised that this (or that) third party tool prior to Vista may have some issues with the new 1 MB alignment. Please note how whilst the "old" cylinder/head alignment was originated (in DOS) by some peculiarities in the actual way the (early) mechanical hard disks worked (that by the time XP came out weren't needed at all, as hard disk had changed their architecture already since years), the 1 MB is a completely arbitrary one, what may or may not make a difference is alignment to a multiple of sector size (so 4096 bytes for newer disks), any multiple would have done as well, and even if they had went ahead, and have only NTFS (which is inherently aligned, while FAT is not unless especially created so, impossible to do with MS own tools only) the cluster size (to make sure to have an integer number of clusters in a volume and no slack space) could have been 64KB (the max cluster size MS uses in its filesystems) or - at the most and leaving some provisions for larger clusters in the future - 128KB. . jaclaz

No. AGAIN clusters have NOTHING to do with disks (and a lot to do with volumes and filesystems). See here: https://kb.romexsoftware.com/en-us/3-general/51-512n-512e-and-4kn-drives https://learn.microsoft.com/en-us/troubleshoot/windows-server/backup-and-storage/support-policy-4k-sector-hard-drives You want to look at values of Bytes per sector: Bytes per Physical sector: and nothing else. It is confusing (and very unfortunate) that the built-in command in Windows to get these values is actually a tool dedicated to gather info on the volume/filesystem (and actually reserved to NTFS only). There seems to be a "more proper" way to look at this info, that works on the disk (not on the NTFS volume) using Powershell, but only on WIndows 8 and later: https://superuser.com/questions/1040865/how-can-i-get-the-physical-sector-size-of-a-drive-that-doesnt-have-any-recogniz Get-Disk | Format-List In Linux, fdisk -l should do. A 512n disk will be seen by any OS as having 512 bytes/sector. (internally it uses 512 bytes sectors) A 512e disk will be seen by any OS as having 512 bytes/sector.(internally it uses 4096 bytes sectors that are "fractioned" into 512 bytes ones transparently) A 4kN disk will be seen by any OS as having 4096 bytes sector. (internally it uses 4096 bytes sectors) jaclaz

Yes , to be more accurate what "may" happen is the following: 1) in XP the "standard alignment is on cylinder/head, so primary partitions will always start on a CHS s=1 h=0 or 1 and end on a CHS s=63 h=max (usually 254, in a nx255x63 geometry) 2) this applies also to logical volumes inside extended, the net result is that each volume will have an offset of 63 from the relative Extended MBR 3) in Vista and later (over a certain - small - size of the device) an alignment of 1 MB (2048x512=1048576) is instead used, and it also applies to the offset to the relative Extended MBR of logical volumes inside extended 4) If you create the Extended partition and logical volumes in XP or however with 63 sector alignment you won't have any issue with both XP and later windows Disk Manager 5) but if you create the Extended partition and logical volumes under a later OS or however with 1 MB alignment, the XP Disk Manager may decide, when performing even an unrelated operation to disk (as an example changing the bootable status of a primary partition), to check/re-calculate the offset of the logical volume from the relative Extended MBR, and silently delete the logical volume entry in the EMBR: https://web.archive.org/web/20160308045741/http://www.dcr.net/~w-clayton/Vista/DisappearingPartitions/DisappearingPartitions.htm See also: http://reboot.pro/index.php?showtopic=9897 The logical volumes are still there (of course) but they are not anymore addressed in the EMBR chain, it is possible to recover them by finding their extents and re-writing proper entries for them, but it needs some time and dedication.. jaclaz

There are also these: https://github.com/DanysysTeam/SFTA https://github.com/DanysysTeam/PS-SFTA the secret hash seems to be not that much secret if it can be generated by a Powershell or Powerbasic script. jaclaz

Final statements: Sector size is determined by the manufacturer of the hard disk and cannot normally be changed (some hard disks, through a proprietary manufacturer tool may allow to switch from 512e and 4kN or viceversa). Some USB adapters/bridges/enclosures might translate sector sizes (from 512 to 4096 or - maybe - from 4096 to 512), in some cases it may be possible to change the behaviour of the chip inside the bridge through a proprietary manufacturer tool. Cluster size is a characteristic of the file system and is normally determined/chosen at the time of formatting a volume. Its value is determined by two fields in the BPB (Bios Parameter Block), usually called "Bytes per sector" and "Sector per cluster", multiplying them you obtain the cluster size, examples: Bytes per sector=512 Sectors per cluster=8 Cluster size=512x8=4096 bytes Bytes per sector=4096 Sectors per cluster=1 Cluster size=4096x1=4096 In the MBR there is NO data related to clusters[1], ONLY about sectors (as seen by the OS), hence the limit of around 2.2 Tib for 512 bytes sectors becomes, when using 4096 bytes sectors (8x), roughly 17 TiB (8x)[2] @Milkinis A 512 (old, traditional) disk has internal physical sector size of 512 bytes AND exposes 512 bytes externally. A 512e disk has an internal physical sector size of 4096 bytes BUT exposes 512 bytes externally. A 4kN disk has an internal physical sector size of 4096 bytes AND exposes 4096 bytes externally. jaclaz [1] AGAIN clusters are determined in the file system, the MBR knows NOTHING about the file system, thus NOTHING about cluster size [2] and this is not how jaclaz "sees it differently", it is how it is

Well, no, you need a similar one (in the sense of one that makes the same translation or no translation) if you want to use the disk normally, but data recovery is possible no matter if the sector size exposed is different, by using *any* other enclosure or connecting the disk drive directly to a computer. Of course in this case you need another suitable disk to copy to, but this is standard procedure when recovering data. jaclaz

As always, it depends. Proprietary enclosures (those disks "born USB" such as many WD and Seagate external units) may have some form of identifying the disk in it (the real issue may come out if you use the provided encryption feature) but, also, some have "non-standard" disks inside (without an actual SATA connector) and in case of problems you would need to trace and solder to the PCB, example: https://blog.acelab.eu.com/pc-3000-hdd-how-to-solder-a-sata-adapter-to-the-usb-western-digital-drive.html Third party enclosures/bridges are simpler as the disk itself is a standard one, and there is no "disk ID matching) so it should work the same in another enclosures (that behaves the same, i.e. either performs or does not perform a sector size translation, and this may happen only when the disk is over a given size or not work at all), here is a related report: https://goughlui.com/2013/10/02/experiment-usb-to-sata-bridge-chips-and-2tb-drives/ There are in any case (though the el-cheapo ones might have size limitations) SATA to USB converters, normally used in data recovery or for temporary access to a disk to be later mounted internal, that work with *any* disk. Just like enclosures, it is extremely difficult if not impossible to know (as the manufacturers do not include this info) how a given bridge will behave. Some chips can be re-programmed using their manufacturer tool (some of them are available for Asmedia chips, as an example) but as well the manufacturer of the bridge or enclosure won't say which chip is used in their product. If the disk is functional, you can always recover the data at file level, even if there is a sector size mismatch, using suitable tools, whether it would be possible to directly restore it may as well depend on a number of factors, hard to say. jaclaz

@Saxon If it (ever) booted it is not a UEFI/BIOS issue. 0x0000007b is inaccessible boot device, so whatever boot device is chosen at the time is likely involved, the error (generally speaking) comes for a missing or mismatched or not working driver. That specific MSI USB drivers can work on a HP laptop would be a strange (I would call it unique) coincidence. And of course you are not going to tell us what it is? jaclaz

Seemingly the guy on that channel uses a "customized" .iso with NTlite adding the Windows 7 MSI USB drivers for his specific motherboard/system to the boot.wim. (of course without giving any meaningful detail on how exactly this was done). He then proceeds to redistribute the modified .iso. So the news are that - [1] - a .iso with a boot.wim with integrated specific MSI USB drivers has issues in a HP laptop. If the .iso is used on a USB stick, which is probably the boot device at the time the BSOD 0x0000007b happens it could well be due to the (wrong/mismatched/whatever) USB drivers. jaclaz [1] Please insert here an adverb, choose among: a. surprisingly b. unexpectedly c. obviously

Of course cannot say for sure, what we know is that XP has had no issues with external USB disks exposing 4k sectors, which for all it matters are the same as 4kn. The 17 TB limit is a theoretical one, the capacity of the field in the MBR is that one, and you are actually using it already when you reach the 2.2TB "limit", so that in itself poses no issues. The NTFS in itself (like *any* filesystem) should depend not on sector size, but rather on cluster size, and XP is included in the OS's where NTFS volumes up to 256 TB are supported: https://support.microsoft.com/en-us/topic/default-cluster-size-for-ntfs-fat-and-exfat-9772e6f1-e31a-00d7-e18f-73169155af95 this does not mean that a number of MS (or third party) tools might have issues with largish volumes. A good example (unrelated) is the mentioned issue with "new" alignment and Disk Manager incompatibility with logical volumes inside Extended partition (that BTW MS never publicized, let alone fix). My "Sure, what did you expect?" note was more "general" and related to the fact that both XP and 7 (and Vista) are not supported anyway anymore and MS has spent time in the last few years to remove references to them and re-writing articles/Knowledge base/etc. to exclude them from lists of supported OS. jaclaz

Another good thing that R.Loew left to us . jaclaz

Sure, what did you expect? jaclaz

I don't understand, you succeeded with the "normal" Vista .iso? But the one you Frankensteined does not work? Never heard of taking a Windows 7 install .iso and replacing in it the install.wim, it may be possible to make it work, but I presume that a number of other changes will be needed. Anyway, the 0x0000007b is "Inaccessible boot device" which - usually but not always - is related to the lack of a proper SATA driver. jaclaz

Yes, it is possible. https://msfn.org/board/topic/149612-winntsetup-v531/ jaclaz

And this in itself means nearly nothing. Most recent disks have 4096 bytes sectors. Then most of them are set as 512e, i.e. while they do have 4096 bytes sectors, they expose to the partitioning/formatting tool 512 bytes sectors. So called "Native 4K" are relatively few. Then comes into play (in case of external disks) the enclosure or the "bridge" in it (be it USB or other). Some of these make no translation, some translate the disk from 512 bytes sector (512e or not) to 4096 bytes, some (hopefully only a few) may even be intended to translate Native 4k to 512 bytes sector.. It is complicated. You could (should) analyze the bootsector of those volumes to understand how they were formatted, checking the fields "Bytes per sector" and "Sectors per cluster" you will be able to make sure what the sector size (at the time the volume was originally formatted) was and the actual (again at the time it was formatted) cluster size. jaclaz

See here: https://msfn.org/board/topic/183250-how-to-disable-the-built-in-xms-driver-in-windows-mes-iosys/ https://github.com/pufengdu/IO8EMMOK jaclaz