AI File Inventories: A Symbolic Link Is Not Another Copy

A small studio asks an AI assistant for a file inventory before handing a project to an editor. The report lists a master document and a second document in a review location. Their sizes match. It is tempting to describe them as two copies, or to assume that the editor can work independently with either one. The report has not yet established either claim.

One entry could be a symbolic link: a filesystem link pointing to another path. For a useful inventory, the distinction matters. The business needs to know whether the report describes stored project material, routes to that material or a mixture of both. A neat list of names can hide that ambiguity.

A file check may follow the link

Python’s Path.is_file() documentation explains that the method follows symbolic links by default. A link pointing to a regular file can therefore pass that check. The related os.path.isfile() reference explicitly notes that a path can be both a link and a file according to its respective checks. Those answers describe different properties, rather than a contradiction.

This creates a precise review question for AI-written code. When a script says “count files”, does it mean directory entries that lead to regular files, or regular-file entries with symbolic links treated separately? Both can be useful reports. They should not share an unexplained label if the owner will use the total to make a decision.

The terminology also needs care. This article concerns filesystem symbolic links. Do not assume that every desktop shortcut, cloud placeholder or alias behaves identically. Ask which types the script supports and test the type that actually appears in the project.

A small test exposes the difference

For this article, a local Linux test created one text file and a relative symbolic link pointing to it inside a temporary folder. A directory scan filtered with the default is_file() check returned both names. The link also passed is_symlink(). The demonstration contained one regular-file entry and one link, rather than two separately saved text documents.

The same test compared size information. Python’s Path.stat() reference states that it normally follows symbolic links; lstat() instead reports information about the link itself. In the test, the default size query through the link matched the target’s size. Adding those two reported sizes would count the target’s logical size twice.

That is a demonstration of reporting behaviour, not a complete measure of disk use. Do not relabel the resulting sum “space that will be recovered” or “backup size” without a separate method appropriate to that question. The useful first correction is to state what the script actually counted.

Decide what the handover needs

Return to the hypothetical studio. If the review location is intended only as a convenient route to the master, identifying that relationship may be enough. If the editor needs an independent working package, ask the handover process to demonstrate that the delivered material remains usable in the editor’s environment.

Keep the inventory and the packaging decision separate. A report that correctly identifies links does not automatically decide whether to preserve each link, include its target or replace the arrangement with an independent copy. Those are project requirements that the owner should agree before accepting a delivery.

A practical acceptance brief might say: “List ordinary files and symbolic links separately. For each link, record its destination and whether the destination can be accessed during the scan. Do not describe a link as a second copy. Report access failures rather than silently omitting them.” Ask the assistant to explain how its code meets that brief.

Keep broken links visible

A missing destination creates another reporting trap. The os.path documentation distinguishes exists(), which returns false for a broken symbolic link, from lexists(), which includes broken links. The difference is important when the purpose is to find references that need attention rather than only material that can currently be opened.

In the temporary-folder test, removing the target left a link that still passed is_symlink(), while the default existence and regular-file checks returned false. The test used disposable sample material. Its result illustrates why filtering a report only to accessible files can leave out precisely the entry a handover reviewer needs to investigate.

For the studio’s proposed inventory, give such an entry an explained status. “Destination unavailable at scan time” is more useful than making it disappear from the report. Do not automatically infer why it is unavailable; the next review should establish whether the project moved, access changed or the reference needs updating.

Use the inventory before deciding to clean up

If an owner sees matching names or sizes, the next step should be investigation rather than an automatic removal plan. MaryChuks’s related guide, AI File Cleanups: Compare Contents Before Choosing a Copy, considers the evidence behind duplicate decisions. Here the earlier question is whether an entry is a copy at all.

Keep this first pass read-only. Request a report that preserves the original path spelling, identifies the entry type and records errors. If the team later proposes changes, review those against the project’s intended relationships. An inventory should make those relationships easier to understand before anyone changes them.

Also record when and where the scan ran. A report describes the environment it inspected, not a promise that the same destinations will remain available after a transfer. Include a destination-side check in the handover rather than treating the source-side list as final proof.

Ask for evidence that matches the claim

Give the assistant a small, controlled example before trusting its report on a large archive: an ordinary file, a link to that file and a link with no available target. Write the expected categories first. Then inspect the output and the code’s handling of each case. This is more informative than checking only whether the script completes without an error.

The aim is a report whose labels deserve their meaning. A route to a file may be useful, and a separate copy may be useful, but they support different expectations. When AI helps produce an inventory, insist that it explains which one it has found before the business treats the list as a handover plan.

Sources

Primary references: Python 3.13 documentation, pathlib: querying file type and status and os.path: file and link checks, checked on 8 November 2026. These are maintained technical references. The studio scenario is hypothetical; the temporary-folder demonstration was run locally for this article and does not constitute a cross-platform inventory test.