Ready to be published? LXer is read by around 350,000 individuals each month, and is an excellent place for you to publish your ideas, thoughts, reviews, complaints, etc. Do you have something to say to the Linux community?
Recently I copied 60 million files from one Windows file server to another. Tools used to move files from system to another are integrated into every operating system, and there are third party options too. The tasks they perform are so common that we tend to ignore their limits. Many systems administrators are guilty of not knowing exactly where the limits of their file management tools lie - at least until they run up against them.
Read the comments on the Register article. The Shill Cavalry got called in to save the day.
The author's problem comes down to an ugly combination of two or three things, at least two of which are basic flaws in the design of Windows.
First flaw: the file system, NTFS, can handle file names and paths longer than the shell (CMD.EXE) can.
Second flaw: NTFS allocates files by runs or extents of disk blocks. The wrong allocation pattern of files can lead to many very short "runs" allocated, a.k.a. fragmentation.
Third flaw: point-n-clicky interfaces to file copying just don't handle largish numbers of files in a directory ("folder" to you baby-talkers). This isn't a Windows problem per se, but certainly the existing Windows APIs tend to exacerbate this.
But the "Windows User Mentality" prevented the author from analyzing his/her problem in this way. The Learned Helplessness led the author to just get 'er done in the quickest possible way, as the underlying structure of Windows won't change in any meaningful way.
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:
|||||
10
Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
The author's problem comes down to an ugly combination of two or three things, at least two of which are basic flaws in the design of Windows.
First flaw: the file system, NTFS, can handle file names and paths longer than the shell (CMD.EXE) can.
Second flaw: NTFS allocates files by runs or extents of disk blocks. The wrong allocation pattern of files can lead to many very short "runs" allocated, a.k.a. fragmentation.
Third flaw: point-n-clicky interfaces to file copying just don't handle largish numbers of files in a directory ("folder" to you baby-talkers). This isn't a Windows problem per se, but certainly the existing Windows APIs tend to exacerbate this.
But the "Windows User Mentality" prevented the author from analyzing his/her problem in this way. The Learned Helplessness led the author to just get 'er done in the quickest possible way, as the underlying structure of Windows won't change in any meaningful way.