Why “Clean” Source Tools Still Miss Things
Cleaning an arXiv source archive is not one deletion task. The problem is to remove or review information across three different surfaces without breaking the document that authors meant to publish. This chapter diagnoses why a cleaner can report progress while leaving exposure behind—or remove a needed input—and then explains how build evidence, metadata processing, structured parsing, rendered-output comparison, and controlled contextual review fit together.
A successful cleanup can still be the wrong result
The most misleading symptom is a source package that looks cleaner after a tool runs. Comments may be shorter, obvious extras may be gone, and the PDF may still open. Those observations establish that the tool changed something and that one build produced an output. They do not establish that all irrelevant information was removed, that the output kept the intended meaning, or that metadata was examined.
There are several possible causes when a “clean” result is incomplete. The first is a mismatch between the tool’s model of source text and LaTeX’s actual structure. A regular expression sees characters and line patterns. LaTeX gives some characters special meanings depending on where they occur. A percent sign can start a comment in one context and be literal content in another. Text outside the document region, a disabled conditional branch, or an argument discarded by a custom command can remain available to a source reader without looking like an ordinary comment line. A pattern that removes visible markers may therefore leave an entire class of irrelevant content untouched.
The same lexical shortcut can cause the opposite failure. If a cleaner treats every apparent comment marker alike, it may alter a verbatim or listing environment, remove content that a package interprets specially, or mishandle an escaped character. The result can still look superficially plausible while changing the paper or preventing it from compiling. This is not a minor edge case when a sanitizer is supposed to be an automated release gate. Under-removal keeps the disclosure surface; over-removal pushes authors toward publishing the unsanitized original because the cleaned version no longer works.
File detection has a parallel problem. A heuristic may decide that a file is safe to delete because its name looks like a backup, or keep it because it resembles a source input. Neither filename is evidence of actual build use. The Hidden Secrets study compares file-level cleaners with a build-access baseline and reports both missed dangling files and removal of files that were still needed. Across the evaluated submissions, half experienced either over-removal or under-removal of dangling files when the cleaners were compared with the baseline. The failure is architectural: the tool is guessing a dependency relationship from surface clues instead of observing the build that creates the PDF.
Even build-aware removal has to distinguish necessity from intention. A file that the compiler never reads may be intentionally supplied as supplementary data. A repository may have conventions for retaining ancillary material or submission instructions. Deleting every unreferenced item can reduce reproducibility, discard a legitimate release, or silently change what readers are meant to receive. The safe interpretation of build evidence is “this item needs a separate decision,” not “this item is always disposable.”