On a case-insensitive filesystem (the macOS default) Foo and foo name one secret, so secret mv --force Foo foo removed the destination, which was the source, and the secret was lost with all its versions. A move between vaults lost it one step later: the copy replaced the source, and removing the source then removed the copy.
Chosen: reject. Before changing anything, a move within a vault and a move between vaults compare the two secret directories with os.SameFile and refuse with secret 'Foo' cannot be moved onto itself: 'foo' is the same secret on this filesystem. A plain rename to the new spelling was not chosen: it cannot be tested without a case-insensitive filesystem (a rename onto a symbolic link to the source fails), and between vaults it would not be a plain rename. On macOS, changing only the case of a name now takes two moves through a third name; README.md says so.
Not visible in the diff:
The check runs before the --force check, so without --force the same move now gets this error instead of "already exists".
os.SameFile is always false on the in-memory test filesystem, so the exact-name check from #76 still covers mv x x there; the new tests use symbolic links in a temporary directory on the real filesystem.
A case-only rename on a case-sensitive filesystem is unchanged; its test skips itself if the temporary directory is case-insensitive.
Model: opus-5-5
On a case-insensitive filesystem (the macOS default) `Foo` and `foo` name one secret, so `secret mv --force Foo foo` removed the destination, which was the source, and the secret was lost with all its versions. A move between vaults lost it one step later: the copy replaced the source, and removing the source then removed the copy.
**Chosen: reject.** Before changing anything, a move within a vault and a move between vaults compare the two secret directories with `os.SameFile` and refuse with `secret 'Foo' cannot be moved onto itself: 'foo' is the same secret on this filesystem`. A plain rename to the new spelling was not chosen: it cannot be tested without a case-insensitive filesystem (a rename onto a symbolic link to the source fails), and between vaults it would not be a plain rename. On macOS, changing only the case of a name now takes two moves through a third name; `README.md` says so.
Not visible in the diff:
- The check runs before the `--force` check, so without `--force` the same move now gets this error instead of "already exists".
- `os.SameFile` is always false on the in-memory test filesystem, so the exact-name check from https://git.eeqj.de/sneak/secret/pulls/76 still covers `mv x x` there; the new tests use symbolic links in a temporary directory on the real filesystem.
- A case-only rename on a case-sensitive filesystem is unchanged; its test skips itself if the temporary directory is case-insensitive.
Model: opus-5-5
PASS: a move within a vault or between vaults is now refused before anything is removed when the destination is the source under another name, and a case-only rename on a case-sensitive filesystem works as before.
TODO.md conflicts with current next; I kept both entries locally to review the code, so the branch needs a rebase before merging.
Not run on a case-insensitive filesystem; the same-directory case was exercised through symbolic links only.
Model: opus-5-5
PASS: a move within a vault or between vaults is now refused before anything is removed when the destination is the source under another name, and a case-only rename on a case-sensitive filesystem works as before.
- `TODO.md` conflicts with current `next`; I kept both entries locally to review the code, so the branch needs a rebase before merging.
- Not run on a case-insensitive filesystem; the same-directory case was exercised through symbolic links only.
Model: opus-5-5
On a case-insensitive filesystem (the macOS default) "Foo" and "foo" name
one secret, so `secret mv --force Foo foo` removed the destination, which
was the source, and lost the secret with every version. Between vaults the
copy replaced the source, and removing the source then removed the copy.
Both kinds of move now compare the two secret directories with
os.SameFile before changing anything and reject the move if they are one,
with or without --force. The tests give one secret two names with
symbolic links on the real filesystem.
Model: opus-5-5
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
On a case-insensitive filesystem (the macOS default)
Fooandfooname one secret, sosecret mv --force Foo fooremoved the destination, which was the source, and the secret was lost with all its versions. A move between vaults lost it one step later: the copy replaced the source, and removing the source then removed the copy.Chosen: reject. Before changing anything, a move within a vault and a move between vaults compare the two secret directories with
os.SameFileand refuse withsecret 'Foo' cannot be moved onto itself: 'foo' is the same secret on this filesystem. A plain rename to the new spelling was not chosen: it cannot be tested without a case-insensitive filesystem (a rename onto a symbolic link to the source fails), and between vaults it would not be a plain rename. On macOS, changing only the case of a name now takes two moves through a third name;README.mdsays so.Not visible in the diff:
--forcecheck, so without--forcethe same move now gets this error instead of "already exists".os.SameFileis always false on the in-memory test filesystem, so the exact-name check from #76 still coversmv x xthere; the new tests use symbolic links in a temporary directory on the real filesystem.Model: opus-5-5
PASS: a move within a vault or between vaults is now refused before anything is removed when the destination is the source under another name, and a case-only rename on a case-sensitive filesystem works as before.
TODO.mdconflicts with currentnext; I kept both entries locally to review the code, so the branch needs a rebase before merging.Model: opus-5-5
secret mvonto the same secret under another name (closes #78)5cfb9c5f46to97d039f1a4