jaclaz

No. No, Who knows? No. No. Cannot really say, it may depend on BIOS, chipset and even IDE cables, let alone adding in the chain an IDE-SATA converter. You can try, and test thoroughfully, if it works, it works, if it doesn't, it doesn't. Now, is the update to 240 GB actually *needed*? Or could you try using a 128 GB SSD and it would be enough? BTW, remember that you can have a 240 GB SSD and on it a 128 GiB/137 GB partition/volume on it without issues. AFAICR, nothing changed in the last 10 years or so: jaclaz

So we can tentatively list on the blackboard, on the "bad" side a few kids: win32 WinClient5270 greenhillmaniac I am not so sure about adding Ximonite , if they are "private" it shouldn't be relevant. jaclaz

The usual 137 GB barrier or 28-bit LBA, you need a suitable driver (not the built-in ATAPI.SYS) or UniATA: https://nt4ref.zcm.com.au/bigdisk.htm jaclaz

Have you checked this? https://www.raymond.cc/blog/12-file-copy-software-tested-for-fastest-transfer-speed/ Results of tests are in a graph on page 2: https://www.raymond.cc/blog/12-file-copy-software-tested-for-fastest-transfer-speed/2/ jaclaz

A good question would be - before making such a general/generic appeal - WHO actually uses mega.nz on MSFN, Anyway, only for the record: jaclaz

I am not fully convinced by the last statement: in the sense that it is probably very true that common drivers do not, but it is not a non-fixable issue, as said the Microsoft own VSS drivers work just fine with 512 and 4096 bytes/sector , and on the other hand there is the Paragon driver (that - with alternate results from reports of people who used it - *somehow* works ), so I would say that "a special driver is needed on XP" (it is the same thing, with a slightly more optimistic view). About the switching between the exposed 512 and 4k sectors (on some WD disks) I am rather convinced that with the right (low level) tools it is entirely possible (in the disk controller itself or in the enclosure controller) to change some firmware settings (as after all the exposing of 512 bytes sector in 512e/512AF disk drives happens to an added - inside the controller - "translation layer") the point is that - even if we find out the undocumented command it may be enabled or disabled (at the whim of the good WD guys) and if it is enabled it is (or will in a next release in case of a new disk/encloure model ) also be supported by the WD quick formatter, but that if it is disabled you will need anyway the hypoyhetical low level tool to enable it. Once said that, there is the additional issue (that we saw in the thread about the MBR 2.2 Tib+rest up to 4 Tib formatting style, that works on 7 but dosn't on XP) of some 32 bit addresses somewhere in some key (files) that unlikely (even if the issue is found) can be patched/corrected. So, the "right" solution for bigger than 2.2Tib disks viable on XP is at the moment only about disks that expose (directly or through an enclosure controller) 4 Kb sectors, Even if it would be a bottleneck/slowing down overlay, I wonder why third party USB enclosures with a selectable pass-through vs. sector size conversion setting aren't available (or maybe they are and we don't know?[1] ) , probably due to the thinning number of XP users, and while I am at it (dreaming) I don't see how a SATA to SATA converter (similar to the el-cheapo's IDE to SATA converters) capable of the sector size conversion cannot be made. UNrelated, but not much: https://www.sabrent.com/acronis/ssc/ jaclaz [1] Possibly the ADU31ESP-X model of Addonics? https://www.addonics.com/products/adu31esp.php P.S.: I found hints - here and there - that the VLI (VIA) 701 is one of these chips that do 512->4K conversion (though I believe it is auto-switching with bigger than 2.2 Tib disk drives): https://goughlui.com/2013/10/02/experiment-usb-to-sata-bridge-chips-and-2tb-drives/ https://www.usbdev.ru/files/vli/ and the "Intenso" controller (whatever it is): https://superuser.com/questions/1271871/4k-emulation-sata-usb-controllers

Yep , your way, "normal" DIR without switches and DIR /b to have "DIR /B" output is also perfectly fine . Maybe you could use (like in other grub4dos commands) the hyphen as separator for switches, i.e. -b, -s, -q, etc., otherwise something *loosely like* : set param1=%1 if not "%param1:~-1,1%==/" <do something inserting a / as first parameter> might do. this should "catch" lines where you omit the / (because in this case the second parameter (switch) is shifted to first) while keeping untouched the provided one, either a single / or a path (like (hd3,0)/) terminated with /. jaclaz

den, the WHOLE point is that disk drives settings CANNOT be changed normally by the end user, if that WD 5 Tb is 4kN, it will remain 4kN, if it is 512e (512AF) it will remain 512e (512AF). SATA disks DO NOT have an OS level tool to change the way sectors are exposed, some (not all) SAS disks (please read as Serial Attached SCSI) do have such a feature. There could well be a manufacturer tool or some other third party software that can enable/disable the 4 kb to 512b translation in the controller (possibly via a TTL interface, not via the SATA, let alone via the USB), but IF it exists, I have never seen/heard of one. jaclaz

Sure , that is exactly where the terminology is confusing. A 4kn disk is 4k sectored AND exposes 4k sectors. A 512e (512AF) is 4k sectored BUT exposes 512 bytes sector. Nowadays anything bigger than - say - 500 GB or maybe 1TB is internally 4k (or at least this is what the manufacturers declare). Actually 4kN disk are pretty much rare, compared with the much more common 512e (512AF). jaclaz

When you copy a file on a "target" disk it is copied (if there is enough contiguous available space) as contiguous, so when you copy a whole set (contents of whole volume) on another (just formatted) volume, it will arrive "defragged". On NTFS there is an exception due to the placement of some of the filesystem metadata files "not at the beginning" of the volume, but it may affect at the most one or a few files, and only if they are extremely large and if they happen to be copied at the "right" moment. (as a side note remember how on NTFS it is a good idea to NOT fill a volume up to the brim, but rather leave some 5/10/15% unused) Once upon a time, in NT 3.51 and early NT 4.00 times there wasn't a "defrag" tool built in in the OS and the "poor man's" solution was exactly that of (using XCOPY) to copy the contents to another volume and then reformat the original and copying them back to the freshly formatted volume. What you propose is essentially a more sophisticated version of the "poor man's" solution above, with the added complication of - if I get this right - the need to phisically disconnect and reconnect the disks exchanging them and the BTW solvable, but not to be underestimated issue with Disk Signature and volume serials (unless you clear the source and copy back the data from the target, that will however take time) . It is a "nice" idea, but I doubt that its objective complication (a second "identical" - or bigger - hard disk available) is either worth it or it applies to more than a few, very particular scenarios is compensated by an increase in efficiency. What makes "normal" defragmentation a bit slower is actually the availability of enough free and contiguous space on the volume, so - in case - it would IMHO make more sense to copy to the second volume only the largest and more fragmented files until you have enough free space, then run a "normal" defrag on the source and then copy back the temporarily moved files from second disk. Another form of optimization (for the booting times only) was once (for the BartPE's and similar) to burn files on CD in the exact sequence they are loaded at boot time. On CD/DVD (please read as very slow media) this had dramatic effects. Later on USB sticks we tried the same approach with (obviously) decreased effects the faster was the stick, on (fastish) USB disk drives the boot time decrease was negligible, I have to presume that on internal disks it will be something that while it can be observed and measured by timing the process, is in practice unnoticeable. The "only" advantage that I can see in this or similar approach on NTFS is that the $MFT will be at its minimal size, but - on the other hand - on a "normally used" volume the $MFT does not usually grow much more than needed (the exception being if you create a zillion files and you later delete them). jaclaz

I don't think that the ls can have the dates/times (on non-fat), it is an internal command, it would need changes to grub4dos itself. What you got now in FATLSDIR.G4B seems to me very good "as is". Personally (but it is just an opinion/preference), I would: 1) shorten the batch name to FATDIR.G4B or DIRFAT.G4B or even FDIR.G4B 2) have the (simplest) output similar to the ls output (only filenames, BUT with a filename per line) without switches 3) have the output with filename and size (and directory total) with the /z switch (I know that it would make more sense to use the /s one, but that is usually associated with the normal DIR /s, where the s is short for recursive , and on the other hand in batch variable expansion %~z1 is size) 4) have the output with added date and time with the /v (verbose) or with the /dt (date-time) switch jaclaz

Side note. When you output a "DIR" listing, you'd better "format" the strings to fixed size. Usually this is done *like* (right align to length 12): set myvar=something #after the = in following line there are twelve spaces set "myvar= %myvar%" set "myvar=%myvar:~-12%" and (left align to length 12) set myvar=something #after the = in following line there are twelve spaces set "myvar=%myvar% " set "myvar=%myvar:~0,12%" jaclaz

I don't know, maybe it is something specific to the WD disks. A virtual disk with 4kb sectors can be partitioned/formatted just fine in XP, at the time I put together the mentioned dual mode batch it has been tested extensively and what I could do on the virtual disk has been replicated just fine on the real disk. It is possible that you need to make the partition table manually, though, @SamirD You have to make up your mind, either most drives are 4kN OR most drives are 512AF (512e). Generally speaking, and AFAIK, disk drives up to 4-6 TB are usually 512AF, larger one are 4 kN (but not always, only as a very rough "rule of thumb") , I would say that 512AF are much more common than 4kN. Changing sector size on SAS (please read as SCSI) is only possible on certain models of disks, and the possibilities are usually between 512 and 520 or 528 bytes/ector: https://linux.die.net/man/8/sg_format https://forums.servethehome.com/index.php?threads/how-to-reformat-hdd-ssd-to-512b-sector-size.4968/ jaclaz

A Sata drive may be EITHER 512 or 512 AF or 4KN . The 512 has 512 bytes sector. The 512 AF has 4 Kb sectors BUT they are translated by the disk controller to "simulated" 512 bytes sectors (the OS can see them a 512 bytes each). The 4KN (4 kb Native) has 4 kb sectors AND they remain 4 Kb (the OS sees them as 4 Kilobytes each). sector sizes CANNOT be changed (a 512 or 512AE translated to 4 kb sectors is not a 4 kb Native). An (external) enclosure with eSata or with USB connections may (or may not) provide an additional layer of translation, i.e. a 512 or 512AF disk in it may (or may not) be translated to 4 Kb sectors . We have a documented specific case of one of such external enclosures that translates from 512 to 4 Kb on the USB bus BUT NOT on the eSATA one: https://msfn.org/board/topic/173265-formatting-an-external-drive-using-different-interfaces/ https://msfn.org/board/topic/173642-mkprilog-batch-to-access-a-same-disk-under-two-different-interfaces/ in practice the eSATA is "pass-through" and exposes the disk "as is", the USB is converting sector size. Such a huge drive (14 TB) is very likely 4kN, it should be possible to partition and format it "normally", without needing the WD tool. jaclaz

You need to create the ,vhd as dynamic, see here: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/gg252579(v=ws.11) OR create the fixed size .vhd as sparse file: https://xenotrope.blogspot.com/2020/04/making-vhd-files-in-qemu-that-work-with.html jaclaz

The router is "self standing", it has a html server for settings, you normally don't need any particular software, *any* browser will do. Likely (check with the provider of the 4G SIM) you have to set a particular APN, compare with: https://www.blinkit.net.au/sites/default/files/blink_s3/HUAWEI_ E5573_User_Guide.pdf Or maybe you need the Huawei "Hilink" app? (some of the router settings may be "locked" by the specific vendor/provider) https://www.youtube.com/watch?v=J0D-5Zdu8mQ jaclaz

As a general note, the VHD can be created as a sparse file (on NTFS fileysystem) or created as a "dynamic" VHD. This way the space taken will be little more than what is actually used (size of contents), BUT you have to consider how - since the file is "growable" and once (partially) expanded cannot be easily re-shrinked - you have to be careful to have enough free space to allow this expansion and be careful on the amount of data you write to it. The usual approach that I personally recommend is to try with a sparse file (or dynamic ,vhd) and use the system, letting the image grow, then make it a fixed size, as the needed size depends on its actual use. If you go for the "sparse" file approach you have to know that unless you take special provisions the file cannot be copied/moved unless special tools are used, in case, see: http://reboot.pro/topic/20487-any-tut-on-expanding-c-partition-on-many-ramdisk/?p=192898 while the "dynamic" .vhd is (externally) a "normal" file (and it can be "compacted" with diskpart). jaclaz

As a side-side note, did you realize that by asking that (needed) single question you indirectly highlighted a whole lot of what is wrong with current Microsoft? jaclaz

Why? This is "Funny Farm", within limits, anything goes here, there is sometimes the need of some (hopefully funny) nonsense, and it is much better here than in the rest of the board, no need for censorship or for taking the toys out of the hands of the kids ... ... unless of course your sensibilities got offended

Just in case: https://www.imdb.com/title/tt0031381/quotes/qt0482223 jaclaz

Since the .ffu is a compressed format, taking a .ffu image of (a whole) disk that has been zeroed out will be only slightly bigger than a .wim (image of the contents of a volume) as 00's compress fairly well. (or of the sum of multiple .wim's in case of multiple volumes/partitions) Yep don't you love the good MS guys, a tool that can basically ONLY be useful in production is not supported in exactly that single scenario where it may be of use (and like if - outside that particular scenario MS support actually existed) jaclaz

Hmmm. And - with all due respect - who cares about what happened (or failed to happen) off site and that you vaguely report here? This is "Funny Farm", personally I am failing to find anything actually funny (or relevant) in your last two posts, we do have a section "Site & Forum Issues" https://msfn.org/board/forum/23-site-amp-forum-issues/ but none that I know for "Off Site Issues". As a side note, do review Rules: https://msfn.org/board/guidelines/ particularly #4.b jaclaz

Post the EXACT model. Check that your SIM is actually suitable for 4G (a - say - 3G SIM won't connect to 4G, no matter what the router is capable of). jaclaz

I think he just said no and everyone else doubted it. Nothing more, nothing less, noone was harassed (at least here), there is not AFAIK any particular conpiracy, nor multiple identities and whatever happened, if it happened, was almost one year ago. I now (genuinely) wonder what you are talking about/what (the heck) do you mean by your post. jaclaz

Yep , as often happen it depends on point of view, on what is "simple". I personally find it simpler to have a small .cmd/.bat like the self-contained batch, de gustibus .... jaclaz