All other similar operations do acquire a lock as so should take-snapshot.

Nevertheless, I suspect there might be an issue here when a write operation persists configuration changes to disk, it performs the following sequence:

1. backup() - moves the main configuration file (uses java.nio.file.Files#move())
2. commitTempFile() - moves the temp file to the main configuration file location
3. fileWritten() - copies the main file to the .last file

Between steps 1 and 2, the main configuration file does not exist on disk. If a take-snapshot operation executes during this window, it attempts to copy a non-existent file and fails.

Zulip discussion: https://wildfly.zulipchat.com/#narrow/channel/174184-wildfly-developers/topic/take-snapshot.20operation/with/575807477

As Brian noted, who at the time did not thing it's a bad idea, it just doesn't change the fact that a snapshot can be out of date because if the concurrent write is blocking for the snapshot it will still immediately execute as soon as the lock is released.