Clarification on Storage.Delete

[anderspitman]

What is your question?

Under what conditions should Delete return an error? This and this seem to contradict each other.

[mholt]

That's a good point. Delete should probably not return fs.ErrNotExist if the key does not exist, but probably should if a prefix of the key does not exist. For example:

• Delete("a/b/c") when c does not exist inside a/b => No error, since that leaf is effectively deleted.
• Delete("a/b/c") when a/b does not exist => Probably an error?

I dunno. What do you think, should it return an error in that second case?

[anderspitman]

I'd be fine with either, though semantically your proposed error essentially boils down to "something I expected to exist doesn't, so inform the caller". So maybe it should return an error in both cases? idk it's not quite the same thing.

In terms of my implementation, what would you guess would be the best behavior to have for now to maximize compatibility with the current release of certmagic?

[mholt]

I'd have to think on it more. (I'll be busy with a conference presentation for the next week though.)

For now, I'd say just return no error, even if the parent dir(s) does/do not exist, but I want to revisit this thinking at some point.

[zllovesuki]

I think that might be an issue if the underlying storage is an object store, say S3. I don't think S3 will tell you about a/b/c differently whether a/b exists or not.

[mholt]

S3 is not a suitable storage medium anyway, as it does not meet the atomicity requirements of the API.

[anderspitman]

@mholt would you mind providing a simple example of where S3 would break atomicity for this? I'm currently reading Kleppmann's book and this would be a nice real world example for me.

[mholt]

@anderspitman S3 does not have an atomic operation such as "create this file only if it does not exist," e.g. O_EXCL.