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

New Issue

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

clawbot commented

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

README-documented bug: multiple files sharing one directory+file number (RAW+JPEG pair, video+THM thumbnail) are one DCF object group per the spec, but the library returns them as unrelated files. Model groups: a group has an index, a primary member, and extension-differentiated members.

Done: a fixture with RAW+JPEG and MP4+THM pairs yields groups with correct membership; ungrouped objects are single-member groups; counts and sizes are per-group and per-member.

README-documented bug: multiple files sharing one directory+file number (RAW+JPEG pair, video+THM thumbnail) are one DCF object group per the spec, but the library returns them as unrelated files. Model groups: a group has an index, a primary member, and extension-differentiated members. Done: a fixture with RAW+JPEG and MP4+THM pairs yields groups with correct membership; ungrouped objects are single-member groups; counts and sizes are per-group and per-member.

clawbot referenced this issue

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

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

clawbot commented

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

Plan. Builds on the parsed DCF objects from #2 and starts after it lands.

Within one DCF directory, files with the same file number form one file group (the README's term); take the exact rule, including what happens when the four leading characters differ, from the spec (CIPA DC-009-2010, https://www.cipa.jp/std/documents/e/DC-009-2010_E.pdf). Files in different directories never share a group.
A group has its directory number, its file number, a primary member and the other members, each member told apart by extension. The primary member is the one the spec names as the main file (the JPEG basic file for a RAW+JPEG pair, the video for a video with its THM thumbnail); say in the PR where the spec states it.
A file that shares its number with nothing is a group of one. Counts and sizes are available per group and per member.
Files not conforming to the naming rules and the PRIVATE/M4ROOT clips are not grouped.
Remove the README's known-bug paragraph about file groups once this works.

Test: a fstest.MapFS card with a RAW+JPEG pair, an MP4+THM pair, a lone JPEG, and the same file number in two directories; assert the membership, primary member, counts and sizes of each group.

Done: as the issue.

Model: opus-5-5

Plan. Builds on the parsed DCF objects from https://git.eeqj.de/sneak/dcf/issues/2 and starts after it lands. - Within one DCF directory, files with the same file number form one file group (the README's term); take the exact rule, including what happens when the four leading characters differ, from the spec (CIPA DC-009-2010, https://www.cipa.jp/std/documents/e/DC-009-2010_E.pdf). Files in different directories never share a group. - A group has its directory number, its file number, a primary member and the other members, each member told apart by extension. The primary member is the one the spec names as the main file (the JPEG basic file for a RAW+JPEG pair, the video for a video with its `THM` thumbnail); say in the PR where the spec states it. - A file that shares its number with nothing is a group of one. Counts and sizes are available per group and per member. - Files not conforming to the naming rules and the `PRIVATE/M4ROOT` clips are not grouped. - Remove the README's known-bug paragraph about file groups once this works. Test: a `fstest.MapFS` card with a RAW+JPEG pair, an MP4+THM pair, a lone JPEG, and the same file number in two directories; assert the membership, primary member, counts and sizes of each group. Done: as the issue. Model: opus-5-5

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:21 +02:00