Meteor tries to delete .meteorsession before saving it

[javascriptlove]

Using the latest Meteor version.
I've recently tried to publish a package using a docker container, thus i'm mounting a .meteorsession file from host to the container (i.e. with -v ~/.meteorsession:/root/.meteorsession), but while publishing of course i got this:

Error: EBUSY: resource busy or locked, rename '/root/.meteorsession.153166' -> '/root/.meteorsession'

What is strange here is why meteor creates a new file to save session info? Looking at this line
https://github.com/meteor/meteor/blob/devel/tools/meteor-services/auth.js#L162
Isn't it too many file operations (create new file, delete the old one, rename the first one)? What's the reason for this? Why not just write to it? Is there a workaround to pass .meteorsession from host OS properly?

[javascriptlove]

And the second question is, why does it try to write a session to .meteorsession if the tokens are the same (and valid)?

[abernix]

The reason it's done in multiple steps is to ensure the atomicity of the file – that is to say, it's not ever in an invalid state (half-written, etc.) when being read by another process.

Presumably, the reason why the session is re-written is to extend the session, though I haven't really looked into it too much.

I'm not familiar with all the intricacies of how Docker would handle it, but have you looked into why the .meteorsession file is locked? Why can't you write to it/why is it locked? Are you able to write to it outside of Meteor?

[javascriptlove]

Thank for clarifying @abernix
Basically, as soon you mount a file (not a directory), you cannot delete it as it will attempt to destroy the link to the Host OS.. And then the new file will no longer be mounted, hence we have the resource locked message.

BUT, you can erase/append/write to it. For now as a workaround, i mount .meteorsession to .meteorsession_copy, then do this upon startup of the container: cp ~/.meteorsession_copy .meteorsession. But then there will be a problem that the host OS session file will old if container runs for long time..

[abernix]

The EBUSY error could be trapped and revert to a cp, but then there'd be a non-atomic operation and the possibility that another readSessionData would fail with an incomplete JSON object. I suppose that is a possibility in the case of multiple meteors running simultaneously. Unfortunately, I think the atomic method is the safer option here and your situation might be in the minority.

I'm actually not sure how long the session is valid for, but I think it's quite a while.

[hwillson]

As mentioned in #8235 (comment), this is functioning as designed. Since this isn't a bug (and there hasn't been enough interest in changing this), I'll close this issue for now. If anyone is interested in changing this, please consider opening a feature request via http://github.com/meteor/meteor-feature-requests/issues. Thanks!