Geth geth snapshot prune-state Fails on Windows

[mtbitcoin]

There is a file permission issue when attempting to run prune on windows. The same command works with linux.

INFO [08-09|12:52:17.527] Iterating state snapshot accounts=142,211,936 slots=481,586,538 elapsed=24m16.894s eta=26.174s
INFO [08-09|12:52:25.535] Iterating state snapshot accounts=142,211,936 slots=483,658,037 elapsed=24m24.903s eta=16.735s
INFO [08-09|12:52:33.542] Iterating state snapshot accounts=142,211,936 slots=485,726,511 elapsed=24m32.909s eta=7.629s
INFO [08-09|12:52:41.129] Iterated snapshot accounts=142,211,936 slots=487,500,091 elapsed=24m40.496s
INFO [08-09|12:52:44.357] Writing state bloom to disk name=C:\Users\Administrator\AppData\Local\Ethereum\geth\statebloom.0x465478226afe866cffe49903dde67846ccfcb175b6a0bb4444c1b4b507427193.bf.gz
ERROR[08-09|12:53:55.372] Failed to prune state err="sync C:\Users\Administrator\AppData\Local\Ethereum\geth\statebloom.0x465478226afe866cffe49903dde67846ccfcb175b6a0bb4444c1b4b507427193.bf.gz.tmp: Access is denied."
sync C:\Users\Administrator\AppData\Local\Ethereum\geth\statebloom.0x465478226afe866cffe49903dde67846ccfcb175b6a0bb4444c1b4b507427193.bf.gz.tmp: Access is denied.

[karalabe]

Out of curiosity, what file system are you using? Just to make sure, it's NTFS + a 64 bit machine, right?

[mtbitcoin]

NTFS and 64 bit, so its not an OS limitation. This might be a permission issue

[karalabe]

Do you have any special things in your file system? Remote mappings? Redirections? Profiles syncing off of and onto some user server?

Based on the logs the file was written successfully. Then closed successfully. Afterwards when we try to open and sync the file, the sync operation fails. That seems very strange.

[karalabe]

Hmm, Open opens the file read only. Wondering if on Windows it's not allowed to call Sync on a read only file?

[mtbitcoin]

I am not familiar with GO but ...Line 93 file open, does that need to have write permissions since we are renaming the file to it's final destination ?

[karalabe]

Yeah, a similar issue was raised on some nodejs repo too, that readonly-sync works on maxos/linux, but not on Windows (nodejs/node#3879). There they say a change to open for write does fix the issue. We can do that I guess.

[karalabe]

@mtbitcoin Could you check if the following diff fixes it for you?

diff --git a/core/state/pruner/bloom.go b/core/state/pruner/bloom.go
index 4aeeb176e..1cd03cf53 100644
--- a/core/state/pruner/bloom.go
+++ b/core/state/pruner/bloom.go
@@ -90,7 +90,7 @@ func (bloom *stateBloom) Commit(filename, tempname string) error {
                return err
        }
        // Ensure the file is synced to disk
-       f, err := os.Open(tempname)
+       f, err := os.OpenFile(tempname, os.O_RDWR, 0666)
        if err != nil {
                return err
        }

[mtbitcoin]

For credit, the line 93 file open was discovered and pointed out by Fudong who works on the BSC geth as we were running into similar issues there.

[holiman]

Technically, Sync does (potentially) modify the file, so it "makes sense" to open in in rw mode anyway.

[karalabe]

Can confirm that the fix still works on Linux. So it's down to a Windows confirm and we can ship it.

[karalabe]

Technically, Sync does (potentially) modify the file, so it "makes sense" to open in in rw mode anyway.

Well, it doesn't in theory. In practice it updates the access time on Windows, and that's probably what breaks.