On 09/10/2019 03.53, Felix Miata wrote:
Is this a known MC or ntfs-3g limitation? First I tried copying from an NTFS USB stick files that originally came from a .tgz file created from an NTFS filesystem. I tried using MC in the Knoppix 8.6 GUI from that stick to an installed SSD's Windows system partition. MC hung around 70% complete, leaving no clue in dmesg. Next try was from the original Windows 7 system partition on the old HD to the freshly installed Windows 7 system partition on a brand new SSD, which froze MC 4.8.23 on openSUSE Tumbleweed at 88% complete, files processed 9533/10387, and again no apparent clue in dmesg. I tried a third time, also using TW, but not selecting any symlinks to copy, and the hang happened at 9531/10370 @Target /mnt/Users/username/AppData/LocalLow/Microsoft/CryptnetUrlCache/Content/ prwxrwxrwx 2 root root 0 Oct 8 19:26 B398B80134F72209547439DB21AB308D_CCF564BE5A3C924B17DDEBDEB5236E1
Is the p in prwxrwxrwx some kind of indicator that failure can be expected absent some kind of decryption environment? There is inexplicably no such file on the source, so I'm at a loss what's happening, and not.
ntfs develops new features now and then. About a year ago I became aware
of a new one that was not supported by news. Let's see if I can find it
(Reparse Points).
Found on nntp:Message-ID:
On 2018-07-28, Peter Pearson
wrote:
I've been happily backing up with rsync for many years, and haven't had this problem before, and have no idea why it started happening.
What should I do to keep permissions information from getting lost?
Any education on the larger picture (there's got to be a reason why there's a system that throws away permissions) would also be welcome.
Because Microsoft was not designed originally for multiuser and so did not think permissions were needed.
FAT32 has no notion of permissions. NTFS has a full suite of permissions. (SID, ACLs, ACE, domain stuff) It has such a large suite of features, nobody can explain all of it. Possibly only Jesper Johansson knows all of it. And if nobody can explain it, that's going to make verifying file system driver behavior a wee bit difficult. https://www.csoonline.com/article/2633083/security/our-windows-vista-securit... Web sites offering tutorials, usually punt before they complete the description. The topic is big enough to need a book. It doesn't mean the obscure features have value, but a complete knowledge of how it works, would mean better output from developers. Linux made the right call, by not implementing any of that for their NTFS driver. Since only reverse engineering was available to figure out how it worked, avoiding permissions and ownership when NTFS is mounted in Linux, makes the interworking practical and sufficient for end-users. And not likely to please any other level of the food chain. So if the NTFS permission model from Linux, looks about the same as FAT32, that's a conscious decision. Linux also does not interact with the USN Journal. And invalidating it is about all you can do, if you choose not to implement journaling on the NTFS file system. Fedora has fixed the Win10 MFTMIRR problem, by commenting out the check. Many other flavors haven't done anything about this yet. If you make an NTFS partition via Win10 Disk Management, Linux may refuse to mount the partition because the MFTMIRR isn't correct, and TestDisk can fix it. A run of CHKDSK from Windows 7 may also be able to put MFTMIRR back into a compatible state. Linux does not support Reparse Points. Nobody can support Reparse Points in any realistic way, since they are custom file system features without documentation. Reparse Points allow extending the file system feature set, without changing the file system version number. A separate metadata file keeps the information needed to handle any files stamped that way. Reparse Points are used to implement Junction Points (a kind of soft link). Even the Windows OS tools choose not to follow such links, and instead a warning is thrown when you hit one (icacls won't touch them). Windows 10 has added a new flavor of file system compression. Without changing the NTFS file system version number from 3.1. It's implemented as a Reparse Point. To allow modifying areas of a Windows C: drive using this feature, in Windows 10 do this as administrator, then take the drive to your Linux box and mount it. This doesn't clear the C: volume entirely of troublesome metadata, but removes certain portions from the Windows folder. As Administrator in Win10 compact /CompactOS:never and that will decompress some but not all, of the affected files. This should not impact data-only partitions, and this detail is only needed when hacking an NTFS C: (OS) partition. NTFS is in fact fully features -- it's too fully featured for its own good. You would swear someone was making these changes, just to make life difficult In Redmond, someone has an evil grin on their face... There may be more than one version of NTFS driver out there. Perhaps the Tuxera commercial one is better. I'm commenting on the one I get for free in a Linux distro, without doing any work. So if you see "I/O Error" in Linux, when attempting to change the filename on a certain file, that's not an I/O Error. That's an inability to handle the metadata on a new-compression format file. At least the MFTMIRR problem or the hibernated disk problem, you're likely to get a dialog explaining what the issue is. The "I/O Error" result comes with no explanation, and naturally, such an error will be scaring the shit out of somebody... (running off to the store, buying a new disk drive, and so on, all for nothing). Paul ...............++- -- Cheers / Saludos, Carlos E. R. (from 15.0 x86_64 at Telcontar)