Skip to content
This repository has been archived by the owner on Sep 6, 2018. It is now read-only.

Windows: log compaction problems #219

Open
philips opened this issue Apr 11, 2014 · 2 comments
Open

Windows: log compaction problems #219

philips opened this issue Apr 11, 2014 · 2 comments

Comments

@philips
Copy link
Member

philips commented Apr 11, 2014

etcd-io/etcd#711

Looks like a straight forward fix.

@MartyMacGyver
Copy link

I stumbled upon bug 711 a little while ago myself and did a bit of digging. In short, this really ought to be fixed in Go itself, but failing that, the easy way is to simply do a create/delete with error checking (the extra space isn't a concern since a new compacted logfile is created before the old one is remove in the rename process, and a mutex already guards the compaction operation.)

If atomicity of the rename itself is a concern then it's more complicated... but other similar bugfixes suggest the proper way to handle this in Windows (e.g., https://bugs.launchpad.net/juju-core/+bug/1240927), particularly the use of MoveFileEx (http://msdn.microsoft.com/en-us/library/windows/desktop/aa365240(v=vs.85).aspx)

This was previously raised as a bug against Go itself (https://code.google.com/p/go/issues/detail?id=3366) but it was rejected on the grounds that atomicity may not guaranteed in Windows. There's a much more thorough discussion of this problem as it affects the Python core code at http://bugs.python.org/issue8828, including a successful resolution.

@MartyMacGyver
Copy link

Update: Since there will be no further movement on correcting os.Rename() in Go, I've opened a request for an os.Replace() function (https://code.google.com/p/go/issues/detail?id=8914).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants