The scan lists the whole folder tree before it checks a photo. On a large
folder on a network share that takes minutes, and the scan's row showed
"0 of 64085" with an empty bar all that while: it looked frozen. ✕ did
not stop the listing either.
- engine: SyncProgress counts the folders and files the walk listed and
says when the listing is over; a folder note (walk::NoteFolder) now
answers whether to go on, and a cancelled scan answers no.
- ui: while the folder is listed, the row has an indeterminate bar and
reads "Listing folders: N folders, M files · folder" (all 13
catalogs); the dialog says the same; then the photos checked are
counted as before.
Co-Authored-By: Claude <noreply@anthropic.com>
The scan asked the disk about every library photo in the folder: is its
file there, and has it a sidecar under any of four names. On a network
share each question is a round trip, and the scan had just listed the
folder. Measured on a hard disk over SMB, for unchanged folders of 1,600
to 2,400 photos: 4.6 to 7.1 s of questions after a listing of 4 to 5 s.
- The walk hands each folder's listing over (`walk::files_in_noting`:
every entry's name and kind, hidden ones too, and whether that is all of
them). The scan walks the folder once, then checks the photos beside
the probing of new files.
- `sync::Listing` answers "is it there" / "is it a file" where that holds
on any file system: a name the folder lists is there; a plain ASCII name
is not there when the folder was listed to its end, all its names are
ASCII and none is that name in another case. Everything else is asked
of the disk as before (a link, a name Windows reads another way, a
folder that was not walked, and every name not listed in a folder that
holds a name outside ASCII).
Now under 0.05 s for those folders. Two things differ on purpose: a file
the folder lists is there though it can't be opened by its path (a folder
that may be listed but not searched, an over-long path), where such
photos were listed as missing; and the answers are the folder as the
walk saw it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Root cause (in 0.2.1 and still on main): files and folders named on the
command line were imported from the eframe app-creator closure with
`app.run("library.import", …)`, which runs the engine command synchronously:
`import::expand` walked the folder recursively (one `is_dir()` open per entry,
no depth or count bound, following links) and probed every file before the
first frame could be drawn. An argument that resolves to a drive root (`.` or
`..` with a launcher's working folder at `C:\`, `/` or `\` on Windows) or to
the home folder therefore walked the whole drive with the window stuck as a
black "not responding" box. The library-problem banner's pending import had
the same synchronous call. Every other recursive walk (Local's Include
Subfolders, Find Missing Photos, preset and LUT folders, MCP) was also
unbounded, which is the "Local folders with subfolders: not responding"
pattern of filmcraft#23, and a link loop recursed until the stack overflowed.
- engine `walk::files_in`: one bounded, iterative walker (32 folder levels,
1,000,000 entries; `Walked::truncated` says it stopped), folder or file
taken from the directory listing (no open per entry), links and junctions
to a folder followed once. `import::expand` (+ `expand_within`), preset and
LUT folder expansion and MCP `expand_paths` use it.
- engine `import::launch_path`: an empty launch argument is ignored; a
relative one is resolved against the working folder; a drive or file-system
root becomes its memory card's DCIM folder or is refused, and so is the home
folder (a notice says why and to use File > Import Photos).
- desktop: launch arguments go through it and are imported with
`import::start_paths` (the import worker), like dropped files; so does the
library-problem banner's pending import.
Not verified on Windows (no machine here). The report says PhotoCraft 0.5.0
and `--memory` hang the same way with no arguments; nothing in LightCraft
walks the disk at startup without arguments (strace of a headless demo run
with HOME=/ and cwd /: no recursive listing), so that part may be outside
this code.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01912WaK6Rmew3wxZuPyX7E8
