sneak/sfdupes
1
0 Fork 0
Code Issues 5 Pull Requests 1 Actions 13 Packages Projects Releases Wiki Activity

Move the command to cmd/sfdupes and the code to internal/sfdupes (closes #157)
check / check (push) Failing after 20m3s
Details

Browse Source 
The root held every .go file in package main, so no ref had the
path cmd/sfdupes that go install was given. cmd/sfdupes/main.go now
only calls sfdupes.Main; the rest is package internal/sfdupes, with
main.go renamed to cli.go. The Makefile builds ./cmd/sfdupes and sets
Version by its new import path. README and TODO.md give the new
install path and file paths.

The test files carry //nolint:testpackage: they test unexported
functions, which the linter allowed only in package main.

Model: opus-5-5
This commit is contained in:
sneak committed 2026-11-10 19:50:51 +00:00
1 parent 7cb10ed303
commit b5ff4f720f
27 files changed
+120 -96
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

TODO.md
+49 -39
View File
@@ -29,6 +29,12 @@
Newest first. An entry ends with its date and its issue or branch, where those
are known.
- The Go code moved out of the repository root. `cmd/sfdupes/main.go` is the
command, and it calls `Main` in the package `internal/sfdupes`. `main.go`
became `internal/sfdupes/cli.go`. Every other file kept its name. The install
path is now `sneak.berlin/go/sfdupes/cmd/sfdupes` (2026-11-10,
https://git.eeqj.de/sneak/sfdupes/issues/157)
- New subcommand `dwim`. It runs what `sfdupes scan /` runs with no flags, then
what `sfdupes trees` runs. Its last line on stderr says that `sfdupes trees`
prints the report again (2026-11-06,
@@ -40,18 +46,19 @@ are known.
walks `sub` on its own instead of dropping it and deleting its records
(2026-11-06, https://git.eeqj.de/sneak/sfdupes/issues/144)
- `README.md` and a comment in `scan.go` no longer say ZFS counts a new file's
blocks only seconds after the write. The count can land in under a second.
Both now say up to seconds after the write, as the comment on `diskSizeOf` in
`scan_test.go` does (2026-11-03, https://git.eeqj.de/sneak/sfdupes/issues/152)
- `README.md` and a comment in `internal/sfdupes/scan.go` no longer say ZFS
counts a new file's blocks only seconds after the write. The count can land in
under a second. Both now say up to seconds after the write, as the comment on
`diskSizeOf` in `internal/sfdupes/scan_test.go` does (2026-11-03,
https://git.eeqj.de/sneak/sfdupes/issues/152)
- The three disk size tests in `scan_test.go` no longer fail at random on ZFS.
`unix.Sync` can return before ZFS has counted a file's blocks, and one ZFS
commit can take a file through several sizes. The test that needs the size to
change waits for it, for at most 30 seconds. Each test reads the size before
and after its scan. The rewrite test rescans until the two reads match, then
compares exactly. The other two fail only on a `disk_size` outside the two
reads (2026-11-02, https://git.eeqj.de/sneak/sfdupes/issues/150)
- The three disk size tests in `internal/sfdupes/scan_test.go` no longer fail at
random on ZFS. `unix.Sync` can return before ZFS has counted a file's blocks,
and one ZFS commit can take a file through several sizes. The test that needs
the size to change waits for it, for at most 30 seconds. Each test reads the
size before and after its scan. The rewrite test rescans until the two reads
match, then compares exactly. The other two fail only on a `disk_size` outside
the two reads (2026-11-02, https://git.eeqj.de/sneak/sfdupes/issues/150)
- `TODO.md` rewritten from scratch by the same rules as `README.md`, sentence by
sentence. Every completed step is kept, with its date and its issue or branch.
@@ -62,9 +69,13 @@ are known.
it. It leads with what the program is and how to use it. A reference section
covers every setting and every subcommand. Development and testing come last.
Every statement was checked against the code on `next`. Five comments in
`main_test.go` cite "Settings", where their rules now live. One comment each
in `scan_test.go`, `trees_test.go` and `exclude_test.go` cites what the README
now says (2026-11-02, https://git.eeqj.de/sneak/sfdupes/issues/135)
`internal/sfdupes/cli_test.go` cite "Settings", where their rules now live.
One comment each in these files cites what the README now says:
- `internal/sfdupes/scan_test.go`;
- `internal/sfdupes/trees_test.go`;
- `internal/sfdupes/exclude_test.go`.
(2026-11-02, https://git.eeqj.de/sneak/sfdupes/issues/135)
- Each record holds `disk_size`, the bytes the file takes on disk. That is its
allocated blocks, `st_blocks` × 512, from the `lstat` call the walk already
@@ -137,12 +148,12 @@ are known.
https://git.eeqj.de/sneak/sfdupes/issues/109)
- The release rule was set. Until 1.0, each tip of `main` that passes the build
gets the next `v0.0.N` tag. `go install sneak.berlin/go/sfdupes@latest` then
installs it. `go.mod` retracts `v0.0.1`, the early build without a database.
When the linker set no version, `sfdupes --version` prints the version Go
recorded in the binary. That is the tag, or the pseudo-version of a
`go install` build. It prints `dev` only when neither is known. README
"Install" documented:
gets the next `v0.0.N` tag.
`go install sneak.berlin/go/sfdupes/cmd/sfdupes@latest` then installs it.
`go.mod` retracts `v0.0.1`, the early build without a database. When the
linker set no version, `sfdupes --version` prints the version Go recorded in
the binary. That is the tag, or the pseudo-version of a `go install` build. It
prints `dev` only when neither is known. README "Install" documented:
- the rule;
- what `@main` and `v0.0.1` give;
- how to check an installed binary.
@@ -393,8 +404,9 @@ are known.
`gomodguard_v2`, so lint no longer prints a deprecation warning (2026-10-04,
https://git.eeqj.de/sneak/sfdupes/issues/26)
- A test fails when either `hashWorker` cancellation check in `scan.go` is
removed (2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/83)
- A test fails when either `hashWorker` cancellation check in
`internal/sfdupes/scan.go` is removed (2026-10-04,
https://git.eeqj.de/sneak/sfdupes/issues/83)
- A database path holding `?`, `#` or `%` opens exactly the file it names
(2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/55)
@@ -402,15 +414,15 @@ are known.
- `scan` rejects `--workers` below 1 as a usage error instead of running
single-threaded (2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/10)
- A test fails when either walk cancellation check in `scan.go` is removed
(2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/81)
- A test fails when either walk cancellation check in `internal/sfdupes/scan.go`
is removed (2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/81)
- A test checks that `scan` refuses a database with another schema version
(2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/64)
- Four inaccurate comments in `cancel_test.go` were corrected, and
`walkCancelInFlightDirs` was renamed to `walkCancelInFlightFiles` (2026-10-04,
https://git.eeqj.de/sneak/sfdupes/issues/33)
- Four inaccurate comments in `internal/sfdupes/cancel_test.go` were corrected,
and `walkCancelInFlightDirs` was renamed to `walkCancelInFlightFiles`
(2026-10-04, https://git.eeqj.de/sneak/sfdupes/issues/33)
- The `-x` filesystem-boundary rules in `subdirJob` are tested (2026-10-04,
https://git.eeqj.de/sneak/sfdupes/issues/17)
@@ -617,15 +629,15 @@ are known.
- `loadRecords`;
- `resolveRoots`.
The single exit point is `run` in `main.go`. It maps a `fatalError`,
anything a subcommand returned, to exit 1, and cobra's own argument and flag
errors to exit 2. So a runtime failure is never reported as a usage error,
nor printed with the usage text. `main_test.go` drives the CLI in-process
and asserts the exit codes from README "Error handling" and the
stdout/stderr split. It also checks that a fatal error after the database is
open leaves no `-wal` or `-shm` file behind, for `scan`, `report` or `trees`
(2026-08-09, branch `db-close-on-fatal`,
https://git.eeqj.de/sneak/sfdupes/issues/4)
The single exit point is `run` in `internal/sfdupes/cli.go`. It maps a
`fatalError`, anything a subcommand returned, to exit 1, and cobra's own
argument and flag errors to exit 2. So a runtime failure is never reported
as a usage error, nor printed with the usage text.
`internal/sfdupes/cli_test.go` drives the CLI in-process and asserts the
exit codes from README "Error handling" and the stdout/stderr split. It also
checks that a fatal error after the database is open leaves no `-wal` or
`-shm` file behind, for `scan`, `report` or `trees` (2026-08-09, branch
`db-close-on-fatal`, https://git.eeqj.de/sneak/sfdupes/issues/4)
- `golangci-lint` was updated to v2.12.2 with the canonical config, merged as
`38a01bd`. The pinned linter in the `Dockerfile` lint stage and
@@ -758,6 +770,4 @@ are known.
# Accepted Divergences
- Flat single-package layout, with the `.go` files in the repo root. That is
fine for a small single-binary tool per the Go styleguide, and the tracker
audit agrees.
None.