From: blockedofcourse@foo.invalid   
      
   On 1/21/2026 4:43 AM, Nioclás Pól Caileán de Ghloucester wrote:   
   > Don Y  wrote:   
   > |-------------------------------------------------------------------|   
   > |"MS has issues trying to transfer large numbers of files via SMB.  |   
   > |And, MAXPATHLEN issues.                                            |   
   > |                                                                   |   
   > |So, if you want to confine yourself solely to the MS world,        |   
   > |you *might* be able to avoid them (try unzipping a file            |   
   > |with a/really/long/internal/path/name/to/a/specific/file to        |   
   > |a folder that is/located/pretty/far/down/in/the/file/system."      |   
   > |-------------------------------------------------------------------|   
   >   
   > Even cutting and pasting in Windows Explorer from C:\ to D:\   
   > failed where the paths differed only by their drives letters   
   > (i.e. their paths are equally long). Windows Explorer reports for a   
   > directory on D:   
   > -   
   > "Size: 2.51 GB [. . .]   
   > [. . .]   
   > Contains: 14,824 Files, 253 Folders".   
   > Such a D:-drive directory came to be on this D: drive by ordering   
   > Windows Explorer to cut and paste from this C: drive, but Windows   
   > Explorer buggily left many files behind on this C: drive   
   > -   
   > "Size: 96.6 MB [. . .]   
   > [. . .]   
   > Contains: 1,190 Files, 59 Folders"   
   > despite copying to D: at least some of what remains on C: - e.g.   
   > D:\ailt_liom\Press-Ombudsman_paper\5u_iarratas_de_2023\Comments.txt   
   > is a perfect copy of   
   > C:\ailt_liom\Press-Ombudsman_paper\5u_iarratas_de_2023\Comments.txt   
   > - Microsoft is bad but thank goodness it did not delete before   
   > copying!   
   >   
   > Remarkably though, maybe Windows Explorer succeeded to copy   
   > everything but failed to delete originals, as only 1 subdirectory   
   > thereof remains on C: and Windows Explorer reported for it:   
   > "Size: 96.6 MB [. . .]   
   > Contains: 1,190 Files, 58 Folders"   
   > and reports for its D: counterpart:   
   > "Size 96.9 MB [. . .]   
   > [. . .]   
   > Contains: 1,191 Files".   
   > Dir/s/b and FC report   
   > that the D: version has   
   > D:\ailt_liom\Press-Ombudsman_paper\5u_iarratas_de_2023\submiss   
   on-to-statutory-review-of-the-defamation-act-december-2016.pdf   
   > and that no counterpart is on the C: version. This missing filename   
   > has a length of only 125 characters.   
      
   Does it contain any UTF-16 characters /anywhere in the path/?   
      
   What's annoying is the filesystem supports things that their   
   standard tools (and API?) seem to not address.   
      
   E.g., I can create file- and path-names that Explorer can't access.   
   So, it's a defect in Explorer.   
      
   Try copying a share with a few million files to another.  Watch   
   to see how throughput drops precipitously!  "Gee, can I restart   
   from a convenient place where it left off?"   
      
   Ever notice how file sizes use different conventions based on the   
   app that is revealing that information?   A 0B file may appear as "1K"   
   (that's a significant difference from 0!)  Or, MiB in some places   
   and MB in another?  Or, "off by one" on size (rounding convention)?   
      
   # du -s *   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)