gopass icon indicating copy to clipboard operation
gopass copied to clipboard

`gopass cp` has a different behaviour depending on whether the recursive directory already exist

Open Stausssi opened this issue 1 year ago • 3 comments
trafficstars

Summary

The copy command has a different behaviour when recursively copying secret directories from one store to another. Even if the --force flag is given, it will recursively copy the directory structure even tho a trailing slash is given.

gopass cp --help states, that the contents will be flattened, if a trailing slash is found. However, the contents are not flattened, if the directory already exists in the target store.

I've also tried every combination of trailing slashes, all with the same outcome:

  • gopass cp --force full-store/some/secret/directory empty-store/some/secret/directory
  • gopass cp --force full-store/some/secret/directory/ empty-store/some/secret/directory
  • gopass cp --force full-store/some/secret/directory empty-store/some/secret/directory/
  • gopass cp --force full-store/some/secret/directory/ empty-store/some/secret/directory/

I could not spot any difference in behavior with/without the --force flag at all.

Steps To Reproduce

  1. Two stores; one contains a directory of secrets, one is empty
  2. Copy the directory to the empty store gopass cp --force full-store/some/secret/directory/ empty-store/some/secret/directory/
  3. Verify the entire directory was copied to empty-store/some/secret/directory/, e.g. with gopass ls empty-store
  4. Now run gopass cp --force full-store/some/secret/directory/ empty-store/some/secret/directory/ again
  5. The secrets were now copied to empty-store/some/secret/directory/full-store/some/secret/directory

Expected behavior

The second gopass cp command should overwrite the secrets in the existing directory and not copy the directory structure as well.

Environment

  • OS: macOS Sonoma 14.5
  • OS version: Darwin FE-C-014F3 23.5.0 Darwin Kernel Version 23.5.0: Wed May 1 20:12:58 PDT 2024; root:xnu-10063.121.3~5/RELEASE_ARM64_T6000 arm64
  • gopass Version: gopass 1.15.13 go1.22.2 darwin arm64
  • Installation method: brew

Additional context

Stausssi avatar Jul 22 '24 12:07 Stausssi

I'd like to work on this issue, Could you please assign it to me?

vijay-kesanakurthi avatar Oct 07 '24 10:10 vijay-kesanakurthi

Thanks for taking the time to fix this!

Unfortunately, I still see the same behaviour:

Assume my source store:

store/
└── group/
    ├── sub-group/
    │   └── secret
    ├── some-key
    └── some-secret

After running gopass cp store/group new-store/group, I see

new-store/
└── group/
    ├── sub-group/
    │   └── secret
    ├── some-key
    └── some-secret

which is what I want to achieve.

However, running gopass cp --force store/group new-store/group again produces

new-store/
└── group/
    ├── store/
    │   └── group/
    │      ├── sub-group/
    │      │   └── secret
    │      ├── some-key
    │      └── some-secret
    ├── sub-group/
    │   └── secret
    ├── some-key
    └── some-secret

I suppose my initial wording was not correct. What I'm trying to get at, is that gopass cp is not deterministic. Running it twice will produce different results.

My goal is to create a separate store with a selected set of the secrets contained in the original store, but kept in sync. I want to sync changes to the selected secrets in the original store into the separate store with gopass cp every time they change.

Stausssi avatar Jan 22 '25 09:01 Stausssi

Let me try to reproduce this (again).

dominikschulz avatar Feb 08 '25 15:02 dominikschulz