Yes. Most filesystems do not guarantee that listing a directory returns files in the same order, so a build that archives or links files in listing order can produce different output each run. Sort your inputs explicitly, using a fixed locale.
The problem in one example
The reproducible-builds documentation uses archive creation as the typical case. Most filesystems do not guarantee a stable order when you list a directory. If a build step packs a directory into an archive and the archive records files in whatever order the filesystem returned, two builds on different machines can contain exactly the same files in a different order, and so have different hashes.
The documentation adds a second trap: when you sort inputs, the sort order must not depend on the system locale. Different locales order uppercase and lowercase letters differently, so sorting without fixing the locale just moves the problem.
Where order sneaks in
- Wildcard expansion in build files. The documentation shows a Makefile whose wildcard result is sorted by the current locale, with two fixes: list inputs explicitly, or wrap the wildcard in the make sort function, which ignores locale.
- Archive creation from directories.
- Generated index or manifest files built from directory scans.
- Hash maps and sets in your own build scripts, whose iteration order can vary by run in some languages.
- Parallel build steps that append to one output in whichever order they finish.
Fixes by situation
| Situation | Fix |
|---|---|
| Makefile wildcard | Wrap in the sort function, or list files by name |
| Shell pipeline into tar | Sort names with a fixed locale and feed them in |
| GNU tar 1.28 or newer | Use its sort by name option, which is locale independent |
| Older tar or other archive tools | Use find and sort with the C locale |
| Own scripts | Sort keys before writing them out |
| Parallel steps | Write results to separate files, then join in a fixed order |
For tar, the documentation gives both forms.
# GNU tar 1.28 or newer
tar --sort=name -cf product.tar build
# older tar
find build -print0 | LC_ALL=C sort -z | tar --no-recursion --null -T - -cf product.tar
It also notes that file order is not the sole archive issue: modification times, owners and permissions may also be recorded, so sorting alone may not be enough.
How to find order problems
- Build twice on the same machine and compare the archive hashes.
- If they differ, list the archive contents of each, without extracting, and diff the listings.
- If the same names appear in a different order, you have an ordering problem. If the names match but metadata differs, you have a metadata problem and need the time and owner fixes.
- Fix and rebuild.
Ordering also matters for tests. A test suite that discovers tests in directory order may pass or fail depending on the machine, which looks like a flaky test but is the same root cause.
Where Safeguard fits
Safeguard produces an SBOM from your lockfiles, and an SBOM lists components regardless of file order, so it stays comparable between runs. Free scan: gold.safeguard.sh/scan.
Quick check
Is sorting enough to make an archive reproducible?
Not on its own. Modification times, owners and permissions are often recorded too and need fixing.
Does a different order matter if the files are the same?
For function, usually not. For proving a build matches, yes, because the hash changes.
Sources
Last reviewed: 19 October 2026.
