I am probably overthinking this, but if there is somehow a file with this suffix already, would we want to error instead of overwrite? We could useflag: "wx" on thewriteFile call to error if the path already exists.

Vanishingly unlikely, but maybe there could be a freak collision where a user has a~/.ssh/config.conf and the random suffix was alsoconf.

1. We could just write to/tmp
2. We could instead name it something likeconfig.vscode-coder.${timestamp}.${randSuffix} to minimize the likelihood of collisions

Thoughts?

I like 2 personally because I think it gives us a better chance to get the temp files for debugging, with/tmp they could be long gone.

But I could see an argument for/tmp to avoid "clutter".

What about a ULID? It would be sufficiently random and you could sort them by time to determine write order when debugging.

If we want to guarantee atomicity, same folder is best (/tmp for instance could be on another filesystem).

To hide clutter in the case of error, I'd suggest a. prefix on the filename, perhaps.tmp.[filename].[rand]. At this point guaranteeing uniqueness beyond this would seem like overkill.

I.e. my suggestion is just/home/user/.ssh/config -> /home/user/.ssh/.tmp.config.XXXXXX.

One use-case that won't work here is if/home/user/.ssh/config is bind-mounted. In that situation we either error out or try to write the file directly. Erroring is obviously safest so perhaps we go with that.

What about a ULID?

I like the idea in theory, but it would be another import.

Forgot to write down one more thing, we should also respect the existing file modes and permissions and make sure they're copied over.

Done. I've also adjusted the tempfile naming convention to~/.ssh/.config.vscode-coder-tmp.abc123 to make it abundantly clear that

1. This refers to~/.ssh/config
2. It was created byvscode-coder