[MC-3208] Command /save-off does not turn off autosaving on server shutdown Created: 16/Nov/12 Updated: 27/Oct/23 |
|
| Status: | Reopened |
| Project: | Minecraft: Java Edition |
| Component/s: | None |
| Affects Version/s: | Minecraft 1.4.4, Minecraft 1.4.7, Minecraft 1.5, Minecraft 1.5.1, Minecraft 1.7.4, Minecraft 14w02c, Minecraft 1.8.1, Minecraft 1.10.2, Minecraft 16w32a, Minecraft 16w32b, Minecraft 16w33a, Minecraft 1.11.2, Minecraft 1.12.2, Minecraft 17w50a, 1.19.3, 23w05a |
| Fix Version/s: | None |
| Type: | Bug | ||
| Reporter: | Josh Johnson | Assignee: | Unassigned |
| Resolution: | Unresolved | Votes: | 17 |
| Labels: | None | ||
| Issue Links: |
|
||||||||||||||||
| CHK: | |||||||||||||||||
| Confirmation Status: | Confirmed | ||||||||||||||||
| Category: |
Commands, Save Data
|
||||||||||||||||
| Mojang Priority: | Low | ||||||||||||||||
| Area: | Platform | ||||||||||||||||
| Description |
| Comments |
| Comment by user-69bf7 (Inactive) [ 06/Aug/20 ] |
|
Still present throughout 1.16. |
| Comment by fuzzyweapon [ 19/Nov/19 ] |
|
Re: Stabel, this is confusing. Most players who want their changes saved will not invoke /save-off, except in the course of a backup. If they forget to re-enable saving then...the backup process is doing it wrong and already jeopardizing loss of data given there are tons of ways that a process can be killed. It seems like you're advocating for a safety net in case these kinds of processes are not tidying up as they should be? But consider a backup that hasn't turned saving back on and the following circumstances...
These are the equivalent of a SIGKILL, and will be problems for backups no matter what. Backup processes should do the right commands.
It's not good form to have another command having magic, undocumented functionality to guard against behavior like forgetting to turn saving back on. At the very least, the documentation for /save-off should be amended.
Best? /save-off works as described and has no side-effects. There's actual use cases for this like running a pvp day on a server that is normally pve and letting people go wild on each other's creations or loading up special mods for an event day that no one wants persisted to disk.
I shouldn't have to login to my host (which I may not have access to a shell to do) and send a SIGKILL. Instances where someone may not have access are due to hosting provider or someone is an operator level 4 but doesn't have shell access to the host.
As someone managing a cloud VPS for a server, I would /never/ give shell access to anyone but myself, period, but I do want to allow other operators who might be throwing events while I'm unavailable, etc to do the above. |
| Comment by Björn Stabel [ 05/Apr/17 ] |
|
snofox If you don't want to stop your server without saving your changes, use SIGKILL(forcekill). That being said, this is a narrow special case which should not endanger the maps of the 99% of players who want their changes saved. |
| Comment by Björn Stabel [ 05/Apr/17 ] |
|
Turaiel I must disagree. Don't force people to go through this. There is no need to. |
| Comment by Anon Ymus [ 19/Aug/16 ] |
|
Reopened and edited. |
| Comment by Brandon Dusseau [ 18/Aug/16 ] |
|
Agreed. If player data is still being saved at all with auto-saving off (and I have confirmed that it is also saving while the server is running), this bug is not fixed. I do not know whether the world saved on server termination with auto-saving off prior to 1.10, but I believe it should not. The wiki indicates that the `save-off` command "Disables the server writing to the world files. All changes will temporarily be queued." This does not specify that this functionality is limited to while the server is running and would lead a reasonable person to believe that the data should also not be saved on termination. |
| Comment by Josh Johnson [ 18/Aug/16 ] |
|
I'd argue that it's not fixed; in fact, it's made worse. As __null said, If saving is turned off, shutting down the server now saves both the world and player inventories; basically rendering /save-off useless. Perhaps reopen with an updated title? Or does this warrant a new JIRA? |
| Comment by Anon Ymus [ 18/Aug/16 ] |
|
I can't reproduce in 16w33a either. |
| Comment by null (Inactive) [ 05/Aug/16 ] |
|
Does this still happen on 1.10.2? I can't seem to reproduce it with the steps in the description – both /stop and ^C seem to save the world and inventories. |
| Comment by Brandon Dusseau [ 08/Nov/15 ] |
|
This is affecting my backup as well. For the time being I'm just going to remove write permissions from the playerdata directory while saving is turned off (i.e. while my backup script is running). |
| Comment by Julian Sivertsen [ 18/Mar/15 ] |
|
Wot, I posted this on another issue. |
| Comment by Julian Sivertsen [ 10/Mar/15 ] |
|
Can confirm that this is still an issue in Minecraft 1.8.1. |
| Comment by Josh Johnson [ 13/Jan/14 ] |
|
Still affects the latest versions of Minecraft. |
| Comment by Naolas [ 30/Mar/13 ] |
|
Some more detail. On save-off the player.dat files continue to be written. As a result, doing a backup will result in player files (player inventory, ender chests, position, ...) to be out of sync with the world region files. This can lead to items disappearing or duplicated items on server restore. I would also be grateful for a any info on a workaround until this can be addressed. |
| Comment by dirk (switched to Minetest) [ 20/Mar/13 ] |
|
Confirmed for 1.5.1-pre server with 1.5.1-pre client. World edits and chests of all types are disappearing. Player position and inventory gets saved, contents of Enderchest gets saved, too (if you place a new Enderchest you get all the items you put in it the last time). |