Cixert

Thanks, it's strange and it's not the first time this has happened to me. The other time I blamed the latest versions 11 and 12 of Minitool Partition Wizard, I don't remember exactly why, but these versions don't work well. Maybe once the partitions were created I formatted them with this one. I don't know, what seems clear is that I created them with DiskGenius since they start in sector 256 and Minitool starts them in sector 2048. If there is any news I will comment. And if anyone knows how Disk Manager deletes partitions just by starting the service, please comment.

Thanks for the help. Finally the culprit was LC Technology - PhotoRecovery When scanning a 3 TB MBR hard drive with logical sector 4096 bytes the program is not able to retain the location of the files found and generates an error copying each file to a temporary location in the .prpro.scratch folder. Once Windows/temp is full it starts filling the first existing partition and once it is full the next one. This is not a justifiable behavior and I don't know how Windows security allows this behavior without user intervention. LC Technology - PhotoRecovery generates a log file with the errors and the behavior, here is an extract: [Devices::Win32::DeviceManagerImpl::rescanDevices] this=[DeviceManagerImpl:]: J:\\ 02:05:18.504 (debug) (T:7828) DeviceManagerImpl.cpp:315 [Devices::Win32::DeviceManagerImpl::rescanDevices] this=[DeviceManagerImpl:]: PD:USBSTOR\\DISK&VEN_TOSHIBA&PROD_EXTERNAL_USB&REV_0\\20221206018168F&0 02:05:18.507 (debug) (T:7828) DeviceManagerImpl.cpp:310 [Devices::Win32::DeviceManagerImpl::rescanDevices] this=[DeviceManagerImpl:]: LD:STORAGE\\VOLUME\\{98433D34-E44C-11EF-9D97-90FBA64B5AC7}#000001635F83B800 02:05:18.510 (debug) (T:7828) DeviceManagerImpl.cpp:312 [Devices::Win32::DeviceManagerImpl::rescanDevices] this=[DeviceManagerImpl:]: K:\\ 02:05:18.512 (debug) (T:7828) DeviceManagerImpl.cpp:315 [Devices::Win32::DeviceManagerImpl::rescanDevices] this=[DeviceManagerImpl:]: PD:USBSTOR\\DISK&VEN_TOSHIBA&PROD_EXTERNAL_USB&REV_0\\20221206018168F&0 02:05:18.514 (debug) (T:7828) DeviceManagerImpl.cpp:318 [Devices::Win32::DeviceManagerImpl::rescanDevices] this=[DeviceManagerImpl:]: ==END LOGICAL DEVICE MAP== 02:05:18.525 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: Z:\\ 02:05:18.528 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: Z: \[2,E\]=Z: 02:05:18.531 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: B:\\ 02:05:18.534 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: B: \[2,E\]=B: 02:05:18.538 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: C:\\ 02:05:18.541 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: C: \[1,E\]=C: 02:05:18.543 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: D:\\ 02:05:18.545 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: D: \[2,E\]=D: 02:05:18.547 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: E:\\ 02:05:18.549 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: E: \[2,E\]=E: 02:05:18.552 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: F:\\ 02:05:18.555 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: F: \[2,E\]=F: 02:05:18.558 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: I:\\ 02:05:18.561 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: I: \[2,E\]=I: 02:05:18.563 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: J:\\ 02:05:18.565 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: J: \[2,E\]=J: 02:05:18.567 (debug) (T:7828) WorkDirectories.cpp:337 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: MP 0: K:\\ 02:05:18.569 (debug) (T:7828) WorkDirectories.cpp:359 [PRApp::WorkDirectories::initVolumeList] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:0)]]: K: \[2,E\]=K: 02:05:18.573 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: B: \[2,E\]=B: 02:05:18.576 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: C: \[1,E\]=C: 02:05:18.579 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: D: \[2,E\]=D: 02:05:18.583 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: E: \[2,E\]=E: 02:05:18.585 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: F: \[2,E\]=F: 02:05:18.587 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: I: \[2,E\]=I: 02:05:18.589 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=[WorkDirectories: ScratchDir=.prpro.scratch Volumes=[(list:9) [Volume: Root=B: WorkDir=B: Enabled=1 Priority=2] [Volume: Root=C: WorkDir=C: Enabled=1 Priority=1] [Volume: Root=D: WorkDir=D: Enabled=1 Priority=2] [Volume: Root=E: WorkDir=E: Enabled=1 Priority=2] [Volume: Root=F: WorkDir=F: Enabled=1 Priority=2]]]: J: \[2,E\]=J: 02:05:18.591 (debug) (T:7828) WorkDirectories.cpp:371 [PRApp::WorkDirectories::rebuildVolumeByPriority] this=

In C:\Windows\Temp I don't see any programs running, but I do see the following folders: \Crashpad -metadata -settings.dat \MsEdgeCrashpad -metadata -settings.dat -throttle_store.dat But these are old folders and files, 2024 February. At this point I have been able to delete all the folders ".prpro.scratch" except the one located at: C:\Users\user_name\AppData\Local\Temp I deleted the files inside and they were recreated immediately afterwards. Also created: -MicrosoftEdgeUpdate.log

It has happened again. My suspicion is that it is a file recovery program, since the recovery drive is the only one that is not filled with these files. This time Renee Undeleter and Ontrack Easy Recovery are closed. So only the following are left open: -EaseUS data Recovery. -iBoysoftDataRecovery. -LC Photorecovery Professional. -Piriform Recuva. Is possible to see in some Windows 10 log who creates these files? In System Events I only see several errors related to the Microsoft Edge update. -EventData 0 crashpad_log No disponible 0 MicrosoftEdgeUpdate.exe 1.3.195.43 InstallError 0x80040902 \\?\C:\ProgramData\Microsoft\EdgeUpdate\Log\MicrosoftEdgeUpdate.log \\?\C:\Windows\TEMP\msedge_installer.log 0 f4b12a7c-ecc8-11ef-9d9c-90fba64b5ac7 262144

No, I didn't know this one

Thanks for the contribution. I had previously posted this error with MBR partitions, but I can't find the post right now. On the 6TB GPT disk connected directly to SATA I created the first partition FAT32 1 GiB cluster 32 KiB aligned to sector 256 with Disk Genius on Windows Seven and then it disappeared just by entering Windows Disk Manager on XP. Now I have created more partitions and the error continues to occur. I will try with another initial sector size when I can empty the disk. If you can do the test with sector 256 and FAT32 cluster 32 KiB I would appreciate it.

I am running several data recovery applications that take several hours to run. When I get to the computer I see that "Renee Undeleter" warns about scratching and I also see the Windows 10 warning "no disk space". I look at the disk drives and see that 8 are full except the attack drive to recover files. All except the system drive contain a folder called ".prpro.scratch" with several GiB in size. Inside there are hundreds of files without extension and all start with the letters PR like: PR0A732D157825533C PR0D2C74353D4D524C PR0D5D2C05570B0007 They measure between 50 KiB and 1.5 GiB. The system drive is also full, but in this case the folder has been created at the path: C:\Users\username\AppData\Local\Temp\.prpro.scratch with tens of GiB. What could be causing this behavior? Other programs I have running are EaseUS Data Recovery, iBoysoftDataRecovery, LC Photorecovery, Piriform Recuva and Ontrack Easy Recovery none of them cause any errors.

Thanks, can you tell me the exact model so I can take a look? Although I'm afraid that these boxes won't allow me to work in Windows 2000/XP with +2TiB disks as Western Digital boxes do, up to 16 Tb, by moving the logical sector from 512 bytes to 4096 bytes.

I have found a new problem working with GPT in Windows XP. Nothing serious if we take the appropriate precautions and also have Windows Vista updated or higher. I found it strange, since the error has not happened to me before. Right now I have the 6 Tb GPT hard disk to which I have only made a 1 TiB partition and left the rest of the space empty. When I open the Windows XP Disk Manager the partition disappears immediately, without performing any additional operation. To prevent losing the partitions I suggest making a partition table copy with Eassos DiskGenius from Windows Seven or higher in the menu Disk>Backup Partition Table. If you do not have a partition table copy, you can recover it with this same program from the menu Tools>Search for Partitions , choosing the Whole Disk option and in the search, clicking on "Reserve" when the appropriate partitions appear. If you know of another suitable program to make a partition table copy, please comment. The pity is that we need Windows Vista or higher or use a bootable CD with a program, since once the partitions are lost in XP the hard disk only shows a capacity of 1493 Gb, so we need to boot an operating system that recognizes the real disk capacity. Maybe it is possible from XP with DMDE, but I don't do it.

Yes, thanks. I bought this hard disk a few months ago and I hadn't used it yet. I hope that the new Western Digital drives are reliable as you say, since in the past I have found otherwise. I'm going to try. Indeed according to BackBlaze, the most reliable is HGST and Western Digital. Although they also list a Seagate drive that has not yet any breakdown. https://www.backblaze.com/cloud-storage/resources/hard-drive-test-data

Of course it is under warranty, but I assume I won't just send them the disk and they will return it to me with the recovered data, right? From what I'm reading from Backblaze's analysis the AFR error rate has increased in recent years across the board for the set of hard drives.

Second hard disk broken this month. This time it's a brand new 2.5" model, a Toshiba PC L200 with 2Tb capacity. After 5 hours of pasting files onto this hard disk via USB 2.0 bridge it started making a clack clack clack sound, which seems like a physical failure. I had the bad idea of cut and paste information onto this drive to use it temporarily as a data drive when I had another drive full. Why doesn't the control Z button work? Another mistake I made was risking using NTFS with a 4KiB cluster for multimedia files. I don't like NTFS, at the beginning of the century I had several Seagate drives broken due to the redundant use of NTFS in the same sectors of the hard drive in the master file table (MFT). Surely sooner or later the drive would have broken anyway, luckily it broke after 5 hours of use with 105GB of information and not later with 2Tb. Is it possible that both drives had mechanical failures due to using the same USB adapter? New with JMicron JMS578 chip which I don't trust to work. https://www.amazon.es/7xinbox-Adaptador-Pulgadas-Compatible-alimentación/dp/B08Y1VQV3Q/ref=asc_df_B08Y1VQV3Q I would like not to argue too much about how bad, awful the Toshiba PC L200 hard disk is. 70 years making hard drives and we still don't know how to do it? Any computer component can be broken, but not the hard drive, please that not! I would like to focus on recovering the data, because this time I have lost 105 GiB (and thank goodness). The two hard disks from which I have extracted them I have not touched. Shouldn't it be easy to recover the data? Over the years I have tried almost all data recovery applications and you know what, I don't like any of them. The attack disk measures 3 Tb with a single FAT32 partition and 32 KiB cluster. A full hard drive scan, as most programs insist, takes several days via USB. I'm currently trying with programs that don't require scanning, such as DMDE, IsoBuster, PC Inspector, Photorescue (Testdisk), and the result is that many files are recovered corrupted. Why can't I recover recently deleted files in another way? How can I physically recover the new damaged hard disk? Several companies offer to do this. Where can I find information on the process? Moral: You have to spend a lot of money to have many hard disks to make backups and never cut and paste. Right now, 2 external hard drives with 8 TB cost around 400 euros.

The disk is aligned to sector 2048 (1024 K for logical sector 512 bytes) I understand that "pciide - bad" in red is because it is in IDE mode. Right now I have the system performing several operations and I cannot do tests, but the speed with the disk aligned usually ranges between 200 and 500 MB/s depending on whether TRIM is performed or not. In XP I have not noticed an increase in performance by doing TRIM with Solid State Doctor 3.0.3.2 (SSD Tools) but I have seen it by doing TRIM with SSD Tweaker Pro 4.0.1 .

These are the values for SDD Kingston A400 connected to SATA port, reported by various tools such as HDDscan & Eassos DiskGenius running on Windows 10 and the command "fsutil fsinfo sectorinfo": Sector Size: 512 Physical Sector Size: 512 However DiskAlignment Test says it is an AF disk and report: Logical block size: 512 bytes Physical block size: 4096 bytes I remember that when I first installed it a few years ago I had problems with partitions allocated to sector 63 that reduced its performance. It's curious the error rate of all the tools. So what I'm looking at is the AS SSD Benchmark Aliggment value in green or red ending in K, which corresponds to the size in KiB of the sectors prior to the indicated partition. That is, if it starts in sector 2048, it gives a value of 1024 K for disks with a logical sector of 512 bytes. That is, the value of the partition offset.

I finally understood it after reading more slowly . Now I understand the reason for using a SATA card. The switch must be set to "no boot" mode or "IDE Boot" for allow recognition of GPT disks with the Paragon GPT Loader v8.0.1.0 driver in an XP system with others hard disks configured in AHCI mode. I only use IDE mode and that's why I didn't understand it. I did tests with AHCI years ago and didn't find any advantage. But well, that's another discussion.

Is this correct? So the switch on the card has to be set to no-boot mode? And it doesn't work with IDE drivers only with AHCI? I think you said at the end that they work in IDE mode. Sorry for so many doubts, but several changes in the publications and not having the card to test it are not clear to me. SATA ADAPTERS* *Only GPT also require Paragon GPT Loader 8.0.1.0 driver ASMedia SATA cards with the asahci32.sys v2.0.3.2 driver installed: Driver Chip --> ASM1061: correct recognition of GTP disks, safe disk removal feature working; Driver Chip --> ASM1064: correct recognition of GTP disks but with AHCI drivers the disks +2TiB have data corruption. Driver Chip --> ASM1166: no recognition of GPT disks.

Magnificent, bravo, stupendous As soon as I have some time in the next days I will try to replicate it on my adapter with chip JMS578

Interesting program: I have never found a reliable way to tell if the disks are aligned. I think the most reliable way is to perform a manual calculation. Right now I am confused with the value given in your screenshot: It says 104424 K OK What does this value mean, the partition size? Running As SSD Benchmark on my partition with XP says 67,804,191 K in red, as if it is not aligned, but I do not have that partition size. Disk Genius says that the partition measures 20,545,276 KiB which results in an effectively unaligned size for a 4096 cluster since it is not a multiple of 8 . On my Kingston A400 SSD hard drive I have resized the partitions a year ago, I do not remember which program I used. I'm running multiple applications now and I get conflicting values for my third primary FAT32 partition running Windows XP, some applications say my partition is aligned and others that it's not. -fsutil fsinfo sectorinfo <letter unit> command run from Windows 10 says: Device alignment: Aligned (0x000) Partition alignment on device: Aligned (0x000) -MiniTool partition Wizard says: Okay MiniTool Partition Wizard needs to align a partition. -Disk Alignment Test: This program is indeed out of date. In the past I've already found that it says some AF disks are not AF and disks that are AF are AF. In theory, if I'm not mistaken my SSD is not AF since it has 512 byte physical sectors. Am I wrong? The program says that it is AF and that I need to align the partition with XP.

USB ADAPTERS I have observed 3 behaviors on USB adapters, when translating logical and physical sectors, regardless of their real logical and physical sectors. 1-The firmware translates the sectors as*: Logical sector 512 Physical sector 512 Observed in models with driver chip: -Innostor IS611 with updated firmware v.923 -JMicron JM20337 *I have seen that all the disks are translated as 512/512 even though these are 512/4096 and there does not seem to be a problem. 2-The firmware translates the sectors as*: Logical sector 512 Physical sector 4096 Observed in models with driver chip: -JMicron JMS578 *I have seen that all the disks are translated as 512/4096 even though these are 512/512 and there does not seem to be a problem. 3-The firmware translates the sectors as*: Logical sector 4096 Physical sector 4096 Observed in models with driver chip: - Innostor IS611 with old firmware v.915 (MBR up to 4 TB & GPT up to 5 TB) -JMicron JMS551 *I've seen all the smaller 2TiB drives translated as 512/512 and there doesn't seem to be any problem even though they are 512/4096 SDDs. We must consider that the real values of these sectors can only be checked with the hard disk connected directly to the SATA port in Windows Vista updated or higher with the commands "fsutil fsinfo sectorinfo <drive_letter>" or on NTFS drives with "fsutil fsinfo ntfsinfo <drive_letter>". These commands also inform us whether the hard drive and partition are aligned. Disk Genius also informs us with the real values of the logical and physical sectors when running it from Windows Vista updated or higher and with the hard drive connected directly to the SATA port. In Windows XP we will only see the values translated by the USB adapter and on the SATA port we will only see the values 512 & 512 even if the disk is 512/4096 or 4096/4096.

OK, thanks for the feedback. I was just updating the information. So the 1062, 1063 & 1064 chips don't work even if they have a switch? I see here the Ubit-SA3004 model that combines the 1061 and 1063 chips. Do you think it works? http://www.evisionde.com/ProDetail.aspx?ProId=92 What switch mode should these be set to? I don't know what is "No boot".

What model card did you buy? I get that it has an chip ASM1061. The photo you uploaded says SU-SA3004.v2. Is this a Ubit? Great, I look forward to your results. I only achieved compatibility with +2TiB hard disks on the USB port with Windows 2003 drivers and USB adapters that specify a 4096 logical sector.

If the first partition starts at sector 63: -Logical sector 512 bytes and physical 512 bytes: 63x512= 32556 bytes 32556:512= 63. Partition starts aligned with the physical sector. -Logical sector 512 bytes and physical 4096 bytes: 63x512 = 32556 bytes 32556:4096 = 7.9482421875. Partition starts misaligned with physical sector. (4096:7.9482421875 = 515.3340705246345 bytes) If the first partition starts in sector 64: -Logical sector 512 bytes and physical 4096 bytes: 64x512 = 32768 bytes 32768:4096 = 8. Partition starts aligned with the physical sector. (4096:8 = 512 bytes) If the hard disk has a 512 bytes logical and physical sector, the partition with a 4096 bytes cluster is always aligned at its start, but it must also be aligned at its end. Otherwise, the first partition will not have all its clusters of size 4096 and the second partition will start out misaligned in relation to the cluster size of the first partition. For this reason, It must be indicated that the partition size is compatible with a 4 KiB cluster, as I mentioned before. Therefore, there are 2 alignments types, one to the physical sector and another to the cluster size. On a hard disk with a 512 byte physical sector, it may not be very important to align the partition to the cluster size, but on a hard disk with a 4096 byte physical sector, it is essential that the partition cluster size be a multiple of the physical sector so that the second partition does not start out misaligned in relation to the physical sector.

Thanks, I intend to use it as an external drive in Windows XP, since I'm noticing that the WD_Quick_Formatter application doesn't work with hard disks removed from the box and this application is necessary to move the logical sector from 512 bytes to 4096 bytes so that it works in XP. In your links I see that My Book has hardware encryption and Essential doesn't. But does My Book Essential have it? I don't want any encryption, I don't have secret files. Regarding the trick of removing the disk from the box, it's something I've always thought about, but manufacturers have also thought that we can do it. So they are putting hard drives with less cache memory than SATA ones. For example, I have tested it with Toshiba Canvio

Searching on Google I found some firmware. The USB adapters I just bought are going to the trash, they are useless. The JMS578 chip that contains Undentified USB 3.0 / SATA Adapter with chip JMicron Tech is too new (2016). I have installed the oldest firmware I have found (v0.1.0.5) and there are no changes. My hard disk is still a 512e logical sector and 4096 physical sector in NT6-10. The JN20337 chip that contains R-Driver III (USB 2.0) and many other models is too old (2004) and I have not found firmware. This always behaves like 512 logical sector and 512 physical sector. It is striking that it works equally in Windows 10 with GPT +2TiB disks. So after looking at its datasheet I come to the conclusion that this is possible because, since update Windows Vista, full LBA-48 is supported. And I suspect that this is the way Paragon GPT Loader 8.0.1.0 works, translating the limited LBA-32 of Windows XP to real LBA-48. Only this way can explain how +2 TiB hard drives work in XP even though Windows XP recognizes them as 512-512. So I will look for other USB adapters, it's amazing that many people on the Internet are complaining that their adapters behave like logical sector 4096 and I find the opposite. Regarding the Logilink AU0028A model (I have 3 units) with Innostor IS611 chip and which is limited to 4 Tb on MBR and 5 Tb on GPT in all operating systems: -With the v923 update, both the logical and physical sectors are changed from 4096 to 512 bytes. Surprisingly, this means that there is no longer a limitation on the hard disk size in NT6-10, but it reduces the hard disks capacity in XP to 2 TB. -The good news is that I have found out how to get it back to 4096 bytes, the bad news is that it is still limited to 4-5 Tb. In the firmware file \Profile\IS611.ini in the value "4k_sector=": =0 disabled both physical and logical 4K. =1 enabled physical and logical 4K. When with 4K I connect my Toshiba WD260 - 6 Tb without initializing the Device Manager on all systems says size 1493.03 GiB. If the disk has already been initialized with another 4K adapter DiskGenius says partition table error. The MBR 4Tb hard disks work without any problems and the GPT 5 Tb also.

Umm, this does not happen to me on GPT, but the following happens to me: -In another hard disk MBR I have the system boot Windows Seven and 10. -When I start XP many times it insist on analyzing this disk with CHKDSK and sometimes it gives me that same uppercase error. If I restart XP it gives me the mistake despite having run CHKDSK. The error is removed for a while when boot Windows Seven or 10. It seems to be some kind of NTFS related error between NT 5.x and NT 6-10.