discovery is extension-grepping, not DCF: parse the CP-3461 structure #2

New Issue

2026-08-30T13:14:38+02:00

clawbot commented

2026-08-30 13:14:38 +02:00

GetDCFStores walks every mounted filesystem root for known media extensions (pkg/dcf/dcf.go). That finds any media anywhere, not a DCF store. Per CP-3461: a store is a volume with a root DCIM/; inside are directories NNNABCDE (100–999 + 5 free chars); objects are ABCD + 4-digit file number. Parse that structure — directory numbers, basenames, file numbers — and expose it on the types instead of only path/size/extension. Non-conforming files under DCIM/ are surfaced as such, not silently mixed in.

Done: a fixture card tree parses into stores/directories/objects with their DCF numbers; media outside DCIM/ is not part of a store; extension lists remain only for classifying object type.

`GetDCFStores` walks every mounted filesystem root for known media extensions (`pkg/dcf/dcf.go`). That finds any media anywhere, not a DCF store. Per CP-3461: a store is a volume with a root `DCIM/`; inside are directories `NNNABCDE` (100–999 + 5 free chars); objects are `ABCD` + 4-digit file number. Parse that structure — directory numbers, basenames, file numbers — and expose it on the types instead of only path/size/extension. Non-conforming files under `DCIM/` are surfaced as such, not silently mixed in. Done: a fixture card tree parses into stores/directories/objects with their DCF numbers; media outside `DCIM/` is not part of a store; extension lists remain only for classifying object type.

clawbot commented

2026-10-03 14:29:15 +02:00

Plan. Follow the naming rules in the spec itself: CIPA DC-009-2010 is the English text of DCF 2.0 (CP-3461), https://www.cipa.jp/std/documents/e/DC-009-2010_E.pdf.

Parse one card from an fs.FS rooted at its mount point, in an unexported function; tests call it with fstest.MapFS, and GetDCFStores calls it with os.DirFS(mountpoint). The public entry point does not change here: its shape waits on sneak's answer on #4.
Under DCIM: DCF directories (directory number 100 to 999, then five characters) and in them DCF files (four characters, then file number 0001 to 9999, then the extension), with the character rules the spec gives. Each object carries its directory number, file number and path; each directory its number and name. The extension lists stay, only to say whether an object is an image or a video. Counts and total sizes keep working.
A file or directory under DCIM that breaks the naming rules is listed separately on the store as not conforming, never mixed in with DCF objects.
PRIVATE/M4ROOT stays part of the card: the README names it as where cameras put video, and the current code finds those clips. Media files there are listed as today (path, size, extension, no DCF numbers). Media anywhere else on the volume is no longer part of the store.
Grouping files that share a number is #3, not this.

Test: one fstest.MapFS card with two DCF directories holding objects, a misnamed file and a misnamed directory under DCIM, a clip under PRIVATE/M4ROOT, and a JPEG outside both; assert where each lands.

Depends on #1. Done: as the issue, with PRIVATE/M4ROOT clips kept.

Model: opus-5-5

Plan. Follow the naming rules in the spec itself: CIPA DC-009-2010 is the English text of DCF 2.0 (CP-3461), https://www.cipa.jp/std/documents/e/DC-009-2010_E.pdf. - Parse one card from an `fs.FS` rooted at its mount point, in an unexported function; tests call it with `fstest.MapFS`, and `GetDCFStores` calls it with `os.DirFS(mountpoint)`. The public entry point does not change here: its shape waits on sneak's answer on https://git.eeqj.de/sneak/dcf/issues/4. - Under `DCIM`: DCF directories (directory number 100 to 999, then five characters) and in them DCF files (four characters, then file number 0001 to 9999, then the extension), with the character rules the spec gives. Each object carries its directory number, file number and path; each directory its number and name. The extension lists stay, only to say whether an object is an image or a video. Counts and total sizes keep working. - A file or directory under `DCIM` that breaks the naming rules is listed separately on the store as not conforming, never mixed in with DCF objects. - `PRIVATE/M4ROOT` stays part of the card: the README names it as where cameras put video, and the current code finds those clips. Media files there are listed as today (path, size, extension, no DCF numbers). Media anywhere else on the volume is no longer part of the store. - Grouping files that share a number is https://git.eeqj.de/sneak/dcf/issues/3, not this. Test: one `fstest.MapFS` card with two DCF directories holding objects, a misnamed file and a misnamed directory under `DCIM`, a clip under `PRIVATE/M4ROOT`, and a JPEG outside both; assert where each lands. Depends on https://git.eeqj.de/sneak/dcf/issues/1. Done: as the issue, with `PRIVATE/M4ROOT` clips kept. Model: opus-5-5

clawbot referenced this issue

2026-10-03 14:29:22 +02:00

DCF file groups: objects sharing an index number are one logical object #3

clawbot referenced this issue

2026-10-03 14:29:48 +02:00

API cleanup: fs.FS-based store access, no *[]DCFStore, contexts on walks #4

clawbot referenced this issue

2026-10-03 14:38:11 +02:00

bring the repo up to repo standards in one PR #1

clawbot commented

2026-10-03 14:38:18 +02:00

State, 2026-10-03: queued behind #1, not dispatched; can run alongside #6. The plan above is the worker's brief.

Model: opus-5-5

State, 2026-10-03: queued behind https://git.eeqj.de/sneak/dcf/issues/1, not dispatched; can run alongside https://git.eeqj.de/sneak/dcf/issues/6. The plan above is the worker's brief. Model: opus-5-5

clawbot referenced this issue

2026-10-03 14:38:21 +02:00

DCF file groups: objects sharing an index number are one logical object #3

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: sneak/dcf#2