XPost: aus.computers   
   From: nospam@needed.invalid   
      
   On Tue, 12/16/2025 11:59 PM, Felix wrote:   
   >   
   > I need to transfer/copy a LOT of files of all kinds, eg. video, audio, text,   
   html, etc., from NTFS formatted SATA mechanical drives via a USB case to an   
   internal SATA mechanical drive formatted in Ext4, but using Nemo the file   
   transfer often stops with    
   an error message 'Input/Output error'. According to Mr. Google this is a   
   common Linux problem with transferring/copying files, and due to inadequate   
   buffering. I tried another copy app ( File Manager PCManFM ) that seemed a bit   
   better but still had the    
   problem. The task is unmanageable while this problem exists. What can I do   
   about it? would more RAM help? I have 16 Gb installed. The CPU is AMD Ryzen 5   
   5500 × 6. and the motherboard is an Asus Prime B550M-K   
   >   
   > Also I notice there have been replies to previous matters I have posted   
   about, but I've been too busy to follow up on them all, but I intend to do so   
   eventually.   
   >   
      
   No, that's NOT where that error comes from.   
      
   Microsoft has sabotaged NTFS by using Reparse Points. The NTFS driver   
   does not have all possible Reparse Points covered with custom driver   
   code. When the Microsoft ICACLS utility runs, it generates error/warnings   
   for each Reparse Point it finds of a certain type, and this is considered   
   normal for the thing. It's not like living in Windows itself, is   
   cosmetically free of blemishes. These traps affect Windows too.   
      
   You CAN have these problems while transferring files from the C: drive,   
   but once you are CD'ed to the Downloads folder, copying the files out   
   of there should work.   
      
   If your files were on the D: drive, and you were seeing that error, then   
   you have an actual I/O error while copying from D: to EXT4. There are not   
   normally a lot of destructive NTFS features on the D: drive unless you   
   add them yourself.   
      
   It's not advised to copy all of C: using any sort of tree copying method.   
   Once you hit a Reparse point, like some of the entries at the top level   
   of C:\users\Felix, will cause a problem while copying at that level.   
   If you CD to C:\users\Felix\Downloads, and then try to copy, that   
   should work. If you CD to C:\users\Felix\Pictures, that should work   
   when you start copying. If you CD the wrong thing, it's going to tell   
   you to piss off. But the important stuff, works.   
      
   *******   
      
   Now, I haven't tried this yet, but make a TAR file out of the C: drive.   
      
   I'm going to do that with 7ZIP, right now. I ran 7zFM.exe as Administrator.   
   Selected Computer from the menu. Highlighted C: under that. Selected   
   "add to archive". It wants to store that as "C_.tar" and I shoot   
   that file over to my D: drive. File is 91,791,916,544 bytes, and the   
   tar process threw at least 2000 errors (which is OK, as none of them   
   involve my Pictures, my Video, my whatsit, they could be system   
   files, like not being able to get into System-Volume-Information is   
   quite quite normal).   
      
   Now I can restore that TAR file on a second machine. For example, using   
   Archive Manager, I could unpack the TAR onto an EXT4, improving   
   the disposition of the on-demand copying you are using.   
      
       [Picture]  This shows the contents of the TAR file, as seen by 7ZIP later   
      
        https://imgur.com/a/w7z05TB   
      
   I hope you have enough storage for this sort of thing :-)   
      
   While you *could* make the TAR or ZIP operations selective   
   on the Windows machine, preparing content for un-archiving   
   on the other end, I'll leave it to you to figure out the details.   
      
   The main point is, if NTFS-handling is slowing you down, convert   
   to an archive, restore on the other end into an EXT4, and THEN   
   do your final value-added copy steps.   
      
   There is more than one NTFS driver for Linux, but I don't   
   think any of them have all Reparse Points. The New Compression   
   Reparse Point, should be defined on at least one of the Linux drivers.   
   But I don't sit around testing crap like this. I already tried to   
   write a utility to parse $MFT, I got part way along, but now   
   I'm stuck on some details. You can NEVER KNOW ENOUGH about   
   the traps Microsoft has laid in there :-/ I found an undocumented   
   structure I can't parse, and it is not a Reparse Point either.   
      
   My archive is restoring on the Linux side of the room, in /tmp.   
   This mounts /tmp on / as a RAMDrive, using around 56GB or so   
   (and leaving a bit for the OS to use, worst case). About 400,000   
   files are going in there, as I type. I will be commenting this out   
   when I finish.    sudo xed /etc/fstab    is where that line is added.   
   The reason for doing this, is it doesn't cost me any SSD wear, to   
   test stuff in this way. I could then go to /tmp/restore/users/Paul/Pictures   
   and copy my pictures out, onto a real EXT4.   
      
   # add TMPFS   
   tmpfs /tmp tmpfs defaults,noatime,nosuid,nodev,noexec,mode=1777,size=56320M 0 0   
      
   When you boot a Live Linux session, half of the RAM is allowed to be   
   used as /tmp, and the RAM is only "booked" if files are stored in /tmp   
   so it is opportunistic usage of RAM in a sense. You might be able to   
   do a remount and change that.   
      
   This process isn't perfect, but the Archive Manager is not complaining   
   as it unpacks the TAR file I made on the other side of the room. No "I/O   
   Errors"   
   so far. OK, it finished, Extraction OK, 422 thousand files on the   
   other computer for picking and choosing.   
      
   And if you have bad or broken hard drives, you can get errors,   
   and if so, do something about it. You can't get much practical   
   usage from computers, without "space to work". And that's getting   
   increasingly expensive.   
      
      Paul   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)