Renaming thousands of files: rules, collisions, path limits and a manifest that proves nothing changed

Write the naming rule as a sentence first

A rule you can say in one sentence can be applied, checked and explained to the next person. For example: year and month, then the subject, then a three-digit number, with no spaces. If you cannot write the rule down, a program cannot apply it. Decide what the rule is built from: the file's current name, its folder, a date in the name, its file metadata or a list you supply. Reading document contents to choose names is a different and larger job.

Decide the folder structure at the same time. A structure that mixes subjects and years under the same level will cause as many problems as the names.

Check names against the rules of where the files are going

Names that work on one system can fail on another. Microsoft lists characters Windows does not allow in file names, namely < > : " / \ | ? * and control characters, and reserved names such as CON, PRN, AUX, NUL, COM1 to COM9 and LPT1 to LPT9, with or without an extension. Names should not end in a space or a period. Windows should not be assumed to be case-sensitive, so OSCAR, Oscar and oscar are the same name there, which makes two files that differ only in case a collision.

Path length is a separate limit. In the Windows API the maximum path is 260 characters, and longer paths work only where a setting is enabled and the application supports it. Microsoft notes you may hit the limit when files with long names go into a folder that itself has a long name. Deeply nested folders add up.

• Reserved names and disallowed characters: flag them in the dry run.
• Case-only differences: treat as collisions.
• Path length: agree a limit below the system maximum so the files still fit when moved.

Run a dry run and approve it before anything changes

A dry run produces a table of old path and proposed new path, with problems flagged, and changes nothing. A named person reads it and approves it. Collisions get a decision: add a number, merge as duplicates after comparison or leave for a person to name. The approval is what makes the later changes yours.

A manifest shows that nothing was lost or altered

A manifest lists every file once, with its old path, new path, size and a checksum. A file that cannot be named safely still gets its row, marked held, so the counts always add up. The BagIt specification describes the same idea for packaging files: a manifest line pairs a checksum with a relative path, so you can check that the set is complete and unchanged. It protects against corruption and mistakes; it is not designed to defeat someone deliberately tampering.

Compare checksums of each source file with the file at its new path. Counts must match across the source, the copy and the manifest. Test the reversal on a sample: restoring the original names from the manifest should work for every file in the sample.

Where the paid job fits, and where it does not

One folder tree of up to 5,000 files can be copied and reorganised as a one-off job from £245 (an untested proposal), accepted by a manifest with a row for every file, matching counts and checksums, a rule check with held files listed, an approved dry run and a tested reversal. Payment follows your sign-off. The files must be handed over as a copy through a secure route agreed in writing first, because the checks compare the contents of every file; no upload portal exists yet, and we do not supply a program for you to run on your own copy. File and folder names can themselves hold a person's name, so folders whose names or contents hold personal data are not covered.

It does not delete originals, remove duplicates by content, choose names by reading documents or advise on retention or legal holds. The first enquiry needs counts and a few example names, never files.