Kimmo Lehto

Maybe I shouldn't be calling Close() at all. I've been doing ```go command, err := shell.ExecuteWithContext(context.Background(), cmd) if err != nil { return fmt.Errorf("%w: execute command: %w", ErrCommandFailed, err) }...

🤔 command.check() is called in the beginning of functions like `Close()`: ```go func (c *Command) check() error { if c.id == "" { return errors.New("Command has already been closed") }...

The `reset`command is a bit dangerous in any case as it doesn't require any kind of confirmation/extra flag, just trying `k0s reset` will immediately destroy everything.

Well, there is of course the safeguard that k0s must be not running. The main problem in this case is that first reset tries to unmount such volumes, but even...

Looks nice. os.Rename isn't atomic on windows btw. I saw some implementation that did the replacing on `Close()` and otherwise it looked like any regular os.File/io.WriteCloser you get from `os.OpenFile`....

> and also has less possibilities to be misused, like double-close, usage from multiple goroutines and such things The caller is usually responsible for calling `Close()` (and/or `Flush()`) for any...

Yes, I meant to suggest dropping the callback and making it a regular writer that just replaces the final target on `Close()`. The expected usage pattern would be the same...

[This](https://github.com/natefinch/atomic) takes an `io.Reader` which kind of flips the happy-path logic around.

If there's a callback then the user shouldn't have to bother with anything else, I mentioned the replace on `Close()` just as the pattern for the callbackless version. The callback...

I believe the problem here is that `Excon`'s `response_block` is called even though the server responds with an error. There's no way to access the response or response headers from...