Notes › Tech Notes › Batch folder scripts: zero-padding and CON are the two easiest traps to miss

Batch folder scripts: zero-padding and CON are the two easiest traps to miss

Creating one drop-box folder per student on a course, plus a submit folder and a grading folder for each, means a hundred right-clicks; writing a script and running it once on the target machine is far less work. The script looks like nothing worth explaining, yet my first run came out two folders short, and on another machine the parent directories did not appear at all, which sent me back to read the output word by word.

The same list, three scripts, not the same kind of command

A list on the left, a body of text on the right, nothing in between. The input box starts with 5 lines, the first four being two-level paths such as Project/Docs; template line 205 generates one on page load, and the first body is a ready-made BAT of 12 lines and 188 bytes. Switching to the other two modes of Folder Batch Creator, the Shell script is 11 lines and 203 bytes, while PowerShell is also 11 lines but 443 bytes, 255 bytes more than BAT.

ComparisonWindows BATLinux ShellPowerShell
Each folder line becomesmd "Project\Docs"mkdir -p "Project/Docs"New-Item -ItemType Directory -Force -Path "Project/Docs" | Out-Null
Nested levels supportedthe whole line fails if the parent is missing-p creates recursively-Force allows parents that do not exist
Header / footer lines4 / 3, plus a pause at the end4 / 24 / 2
With 150 folders157 lines / 3544 bytes156 lines / 4429 bytes156 lines / 11049 bytes

Line count depends only on folder count: BAT is N+7, the other two are N+6, and from N=1 to 150 everything matches, with the command count always equal to N. Those 150 lines came from 3 root folders with 50 numbered entries each, the first Project/folder_001 and the last backup/folder_050. The extra BAT line is a closing pause that waits for a key press; the other two do not stop.

Windows BAT 157 lines / 3544 bytes Linux Shell 156 lines / 4429 bytes PowerShell 156 lines / 11049 bytes

Figure 1 | Byte count for the same 150-line list, bars scaled by bytes; PowerShell repeats the whole New-Item argument string on every line.

Whether a slash builds levels is decided by only two modes

In md "Project\Docs", cmd's MD has no recursive switch, so a missing parent makes the whole line fail; only the -p and -Force versions land. The separator is passed through replace once, the source has no loop that splits levels, IF EXIST and for /d appear 0 times, so the page claim that nested directories are created automatically holds for only two modes.

Fewer padding digits will not collide, but it changes names

I used to believe a width smaller than the number would collide, with the extra digits cut off. It does not: padStart only pads on the left and never truncates. With width 2 and numbers 1 to 200, items 98 to 102 are folder_98 folder_99 folder_100 folder_101 folder_102, and all 200 names are distinct. Exhausting widths 0 to 6, starts 0 to 50 and ends up to 200 gives 357 configurations and 5599307 names, with 0 collisions.

Longest name length p=0 folder_1 8 p=2 folder_01 9 p=3 folder_001 10 default p=4 folder_0001 11 p=5 folder_00001 12 0 duplicates; p=1 and p=6 are not offered

Figure 2 | Start 1, end 5, measured per width: widths 0, 2, 3, 4 and 5 give longest names of 8 to 12 characters, longer but never duplicated.

The cost is elsewhere. For the same 1 to 12, width 2 starts at folder_01 and ends at folder_12, one length; width 1 mixes two lengths, and sorting and wildcards go out of step. Negative numbers are blunter: start -1, end 1, width 3 gives folder_0-1 folder_000 folder_001, with the zero padding running to the left of the minus sign, and min="0" only drives validation styling, the code does not clamp. Remember the default: width 3, start 1, end 50 produces folder_001 through folder_050, 50 folders, not the folder_01 to folder_99 used in the copy.

CON and nul go straight into the line

I ran 25 names through it: the six reserved names CON, PRN, nul, AUX, com1, LPT9; names with spaces and tabs, with slashes and backslashes, with colon, asterisk, question mark, double quote, angle brackets and pipe; the dot-only .. and ...; plus two identical END lines. Each of the three scripts writes 25 commands, the same as the number of input lines: no deduplication, so END appearing twice gives two commands, and 0 validation of reserved names or illegal characters. The failure waits until the script runs: Windows only refuses those characters and COM1-9, LPT1-9 at CreateDirectory, and a name containing an English double quote closes md "quote"name" early. Duplicate lines are written too: deduplicating 6 input lines leaves 3 commands, and BAT reports that the directory already exists or is invalid the second time it hits the same target.

Validation in one place, and a stale output area on error

The code that builds the list validates in only 1 place: when the end number is lower than the start number it says the end number must be greater than the start number and returns immediately. The side effect is worth remembering: neither the output area nor the stats refresh. I ran the 150-line version, lowered the end number, got the error, and the screen still held the previous 157-line body, so copying at that point hands you the old script.

Every other boundary is silent: leave the start empty, put 3 in the end, parseInt gives NaN and falls back to 0, so you get 4 folders from 0 to 3 while thinking there are 3; an end of 1e3 reads as 1; a non-numeric width falls back to no padding and gives folder_1; the prefix is not cleaned, so 30 characters with 1 to 60 yields 60 names of 34 characters. Two safe details worth mentioning: pasted CRLF is split on LF and each line trimmed, so the CR is eaten and never reaches a folder name; the stats area has just 2 items, folder count and script type.

Copy, download and line endings

The download name is always create_folders plus the extension, .bat, .sh or .ps1, with no timestamp and no random string; all three bodies use LF line endings with 0 lines containing CR, so the .bat does not bring Windows line endings with it. Lists are often dirty: for a batch of full paths I feed them to extract filenames from paths to keep the last segment, and for names scattered in long text I pull them out with batch extract information by rule, then generate.

Q: Why were two folders missing after the run?

The command count always equals the number of list lines; what is missing are the lines the runtime refused. 25 special names still produce 25 commands, and reserved names and illegal characters only fail at CreateDirectory. The other cause is duplicate lines in the list, where 6 lines leave only 3 folders.

Q: folder_001 or folder_01, which is right?

Neither is wrong, but the default is folder_001 through folder_050 because the width is 3. For folder_01 you have to switch to 2 digits, and for folder_1 choose no padding; the width only decides padding length and never causes collisions.

Q: Will the script overwrite existing files?

This check only established one thing: the tool does no checking and never touches the disk, so behaviour is entirely up to md, mkdir -p and New-Item. The only confirmed case is that BAT reports the target already exists or is invalid on a second hit at the same directory.

📎 Related articles

PNG compressed three times only lost 426 bytes: the real boundary of lossless compression 2026-10-22 How Many Times Bigger a PNG Gets After Converting From WebP: When It Is Unavoidable and How to Keep the Growth Down 2026-10-22 Three Reasons the Small Text Smudges When a Screenshot Is Shrunk to a Quarter 2026-10-22 Cropped to the Same 300x300, Why Does the Avatar Always Sit Half a Cell Low-Right 2026-10-22 Forecasting 18 months at 1.7 times a month: why the script and the sheet give two numbers 2026-10-22