Looking at the sample code in PR#14, I assume that one would replace a, err := file.New(path) with a, err := accessor.New(path) for an encrypted file, yes? Assuming that's the case, would it make more sense to call this package encryptedfile instead of accessor to clarify the distinction?

Maybe the idea is that we want folks to always use accessor, which is why the unencrypted implementation is a subpackage under accessor?

Assuming that's the case, would it make more sense to call this package encryptedfile instead of accessor to clarify the distinction?

The macOS and Linux implementations don't use a file for storage. There may be a better name for this though. My thinking with "accessor" is that it has everything that accesses storage, and accessor.New() builds the encrypting accessor for the platform.

Maybe the idea is that we want folks to always use accessor, which is why the unencrypted implementation is a subpackage under accessor?

That's the idea. Applications should prefer encrypted storage. The file package is a fallback for (typically Linux) applications that can't use our crypto dependency.

Agreed having "file" in the name doesn't make sense.

Is accessor always used with cache, or are there scenarios where it's independently used? If it's the former, what about placing it under the cache directory? Then the fully qualified name contains /cache/accessor.

That makes sense and I don't see a reason not to do it. Can't prevent applications running wild with exported types but the supported scenario is using accessor with cache.