Chunks do not delete properly remaining in a newly created world if the same world name is reused

Have you tried deleting these incorrectly generated chunks via some third-party program such as MCedit. From the results of this test you could determine whether this is a slight flaw with flatland generation or the game neglecting to read the NBT tags of the save before generating these chunks and therefore generating them as it would with a normal world. This also seams to be the same issue as MC-204.

Commonly seem when the world name is reused. Old world didn't have time to delete and new one used the same folder name as the old which contained undeleted chunks. We're looking at user error.

Ive Seen This Aswell Exept The Biome Was Desert And There Were Jungle Trees and It Was Snowing!!??

I had it on 1.2.5.

This issue is a follow up of MC-526

It is still in 13w04, I can comfirm it.

one way to fix it could be probably to force minecraft to check for any world files/region folder/DIM* folders present when creating a new world, before world generation and delete them before being allowed to generate new ones. in case any files are inaccessible/read only show an error and return to world creation menu.

unless that's already happening and didn't help.

Crude fix
MCP naming...

Minecraft.launchIntegratedServer()

...
    ISaveHandler var4 = this.saveLoader.getSaveLoader(dirName, false);
    WorldInfo var5 = var4.loadWorldInfo();

    if (var5 == null && par3WorldSettings != null) {
        // A new world, ensure deletion of possible old junk and reinitialize var4:
        this.saveLoader.deleteWorldDirectory(dirName);         // ADDED
        var4 = this.saveLoader.getSaveLoader(dirName, false);  // ADDED
            
        this.statFileWriter.readStat(StatList.createWorldStat, 1);
        var5 = new WorldInfo(par3WorldSettings, dirName);
        var4.saveWorldInfo(var5);
    }
    ...

It is kinda bad coding, but I am trying to keep using existing methods. The ugliness comes from that method handling both new and existing worlds, and it needs to init and use both var4 and var5 in order to know if the world is new. But by that time those calls have already created the world directory and a file, which the deletion then immediately remove. Thus it needs to redo the var4 stuff.

The proper fix would be add a new method that specifically checks the existence of world save left-overs and then cleans them up, and use that method from those places which create new worlds (and only create, not open existing ones).

Tested on 1.4.7, works wonders. My messed up results from testing MC-526 and sheep color testing, and even manually "broken" world save directories were all handled correctly. That is, the world creation first wiped the remains of the old directory (confirmed by watching the console and checking that marker files disappeared) before generating the new world with the same directory name.

Guys, My brother found it he has the one who said me to post it. Sorry!

I had this once but than th other way around with the superflat in the middle and default around it...
looked like 'the end of the flatlands'

I got this with an extreme hills (which for some reason had jungle trees on it...!?) in 1.5.2

Confirmed in 13w22a

it did it to me in 13w22a

Confirmed in 13w25c

Confirmed on 1.1 (superflat introduced) - prerelease 1.6.2
this bug ANNOYS ME!

@SteelCrow we are not looking for user error.
Steps to reproduce:
1. Make a world
2. Leave world
3. Delete world (singleplayer ==> select world ==> press delete world ==> Are you sure? YES)
4. Create new world with exactly same world and directory name.
5. Old chunks remains in new world.
This is not user error, this is error in the game code. I'm waiting that someone from mojang fixes this.
In mean time, let's just cuddle :3

@crazyman: those steps (as described) are not always enough, as timing is part of the problem. Better description for reproduction in the comments of the related MC-526. (The crucial thing is to do the step from leave world -> delete world quickly; on my machine (SSD drive etc) I have to even exercise a bit (e.g. to know to move mouse cursor to proper spot even before I can see the button to be pressed) in order to be quick enough.)

Apart from the user error part, Steelcrow's comment was otherwise correct, and was one of the comments that allowed me to find the problem code quicker.

As another note, there are more duplicates than votes for this issue. Sigh.

Please add that it affects Mac OSX.

Im having a similar problem with jungle biomes.

Potentially fixed this issue. I'm not able to reproduce it so I'm not 100% sure. Please test and let me know, thanks 🙂

Reopening due to MC-34303

MC-34303 does not necessarily justify a reopening of this ticket, if there are still old region files laying around on the harddisk (by this bug in older versions), then creating the world with the old name in 13w39b will of course show this effect too.

Actually, it does justify reopening this issue, but not the related MC-526. This issue is now profiled more about deleting any garbage at the time of taking a possible old folder to be reused - whatever the reason for having that garbage there.

My crude fix shown in a previous comment does just that; even if some ancient stuff is around, they are cleared out first. That action is also necessary even if the deletion process is fixed, as there could still be events which interrupt deletion, like crash or power-down etc. and those can not be avoided or handled at deletion time. They must be handled later, at the time of creating a new world. (A fancy fix might occasionally try to check and cleanup folders that are obviously no longer in use but have some garbage...)

The MC-526 is purely about the deletion itself, when the action is started by the player, but fails to complete (for reasons that can be fixed and avoided). No need to even try to create another world by the same name. This MC-315 is just the most common consequence of the MC-526. But not the only consequence for it, and there are other reasons for MC-315 than having MC-526 first. (Thus, the need to have these separate issues for them.)

Markku, you are absolutely right.

This is still an issue in Minecraft version 14w03b.

@unknown: Please attach the development console when having this issue.

@unknown: Can't get it to work right now, I'll try again tomorrow.

Logfile in https://bugs.mojang.com/browse/MC-526?focusedCommentId=134792&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-134792

Confirmed in 14w05b (OSX 10.8.5, log attached).

Just accidentally created a checkerboard of two different worlds due to the deletion of the previous world failing to complete before a new world (with the same name) was created.

I meant to create a new Creative world but created a Survival world by mistake (as "New World"). I quit out to the menu, deleted the Survival world and created a Creative one instead (also "New World"). Creative world has a mixture of chunks from the deleted world and the world that actually goes with the seed given by /seed.

Edit: Actually, this may be an instance of MC-526 instead.

Note, the sequence used by Bruce also indicates that MC-526 affects 14w05b (couple more versions than the latest reported). The delete and recreate -sequence, when causing issues, automatically confirms both issues (as both the deletion fails at the time of deletion, and no attempt to clear the old dir is made at the time of creation).

happened to me 2, but when i first spawned it was nt there.. 2 weeks later its like random walls grew. And now my dirt is retextured to look like its glowing.

Unfixable. Searge's comment from MC-62627:

Leaving a world, then immediately deleting it and creating a new one with the same name can, in some cases, cause issues with chunk generation.

So the problem is actually with the world/chunk generation and not old files not being deleted properly?

Andrew, look at the log on my comment. The error being reported is:

[20:24:11] [Server thread/ERROR]: Couldn't save chunk; already in use by another instance of Minecraft?

Basically, old chunks from one world can't be overwritten by worldgen in the next.

Blah, I'd accept "Don't do that then" as a bugfix...

@@unknown: It's the server still saving the world files while the client tries to delete the files:

[00:19:42] [Server thread/INFO]: Saving chunks for level 'Flatworld6'/Overworld
[00:19:42] [Client thread/INFO]: Deleting level Flatworld6
[00:19:42] [Client thread/INFO]: Attempt 1...
[00:19:42] [Client thread/WARN]: Couldn't delete file C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region\r.-1.0.mca
[00:19:42] [Client thread/WARN]: Couldn't delete directory C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region
[00:19:42] [Client thread/WARN]: Unsuccessful in deleting contents.
[00:19:42] [Server thread/INFO]: Saving chunks for level 'Flatworld6'/Nether
[00:19:42] [Server thread/INFO]: Saving chunks for level 'Flatworld6'/The End
[00:19:43] [Client thread/INFO]: Attempt 2...
[00:19:43] [Client thread/WARN]: Couldn't delete file C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region\r.-1.0.mca
[00:19:43] [Client thread/WARN]: Couldn't delete directory C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region
[00:19:43] [Client thread/WARN]: Unsuccessful in deleting contents.
[00:19:43] [Client thread/INFO]: Attempt 3...
[00:19:43] [Client thread/WARN]: Couldn't delete file C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region\r.-1.0.mca
[00:19:43] [Client thread/WARN]: Couldn't delete directory C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region
[00:19:43] [Client thread/WARN]: Unsuccessful in deleting contents.
[00:19:44] [Client thread/INFO]: Attempt 4...
[00:19:44] [Client thread/WARN]: Couldn't delete file C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region\r.-1.0.mca
[00:19:44] [Client thread/WARN]: Couldn't delete directory C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region
[00:19:44] [Client thread/WARN]: Unsuccessful in deleting contents.
[00:19:44] [Client thread/INFO]: Attempt 5...
[00:19:44] [Client thread/WARN]: Couldn't delete file C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region\r.-1.0.mca
[00:19:44] [Client thread/WARN]: Couldn't delete directory C:\Users\User\AppData\Roaming\.minecraft\saves\Flatworld6\region
[00:19:44] [Client thread/WARN]: Unsuccessful in deleting contents.
[00:19:57] [Server thread/INFO]: Starting integrated minecraft server version 14w29b

Blah, Andrew and Bruce, and Sonic:
Read my comments in both this issue and MC-526.

• Both are fixable, and can be quite easily at least improved so much that we wouldn't get 180 duplicates... (And Searge's comment in MC-62627 in no way claims that these are not fixable, he merely states the reason for that issue to be this bug.)

• The issue is both failing to delete a world properly at the time of deletion, and failing to delete the remains at the time of creating a new one. (The first is obviously good to have, the latter is a must.)

• "Don't do that then" is a joke, not a valid solution for these issues. These issues are not user errors, but coding bugs.

There are, in a way, two issues caused by one failure. However, both issues should be fixed as the MC-526's "worlds will not delete" can not be 100% ensured in e.g. crash situations (power outages etc.). The world deletion can be made more robust (I've even provided some suggestions of tested fixes). The lingering worlds can be deleted (100%) properly before taking them into new use (I've even provided some tested, though ugly code fixes).

These issues have now been, and has been for last 1.5 years, only waiting for Mojang dev's to adapt those fixes to their code (or make even better fixes if they want).

one way to circumvent it until fixed would be to rename the newly created world on creation if previous wasn't deleted completely and its folder/files still exist.

say, you make world called "new world", then delete it (but deletion fails) and make a new one called the same. instead of calling its folder "new world" too and causing the bug, just auto rename it to "new world_1" or involve a date+time, like "new world_20140723151905" to prevent multiple attempts to create the same name.

that way even if the world fails to delete, new one won't be able to overwrite its remains, taking some of its chunks in since it'll go to a different folder.

the remaining one could be scheduled to be deleted on next minecraft launch, and if it still fails then, reschedule for next and keep doing it until successful. one pc reset later the folder will be finally freed and will delete normally.

Confirmed 14w30c

I have one chunk in my main SSP world, next to my guardian farm in a deep oceanthat does not belong there. It seems that the biome info is overwritten because the chunk is clearly a forrest but every block on it is a deep ocean biome.

Confirmed in 1.8.1-pre3

I love how my report on MC-204 is older than this one but still got closed for the reason "duplicated". I'm actually quite surprised I accessed randomly MC-204 and saw I was the reporter, too.

@unknown probably because this report here contained the cause for this bug. It happens sometimes that Mods close older reports because they contained less information

I can confirm it for 15w32c

Confirmed in 1.8.9. I generated a new superflat world with the dirt preset changed to 50, so it can be deeper. I teleported to 0 62 0, the center of the world, set my spawn, and started building. However, I soon saw a large structure in the distance, and I realized that it was a chunk. I saw a bunch of them, and it was really scary. I deleted that world. The thing is, I had created a world before this, but I forgot to set it to superflat and creative mode. It was normal and was in survival. I suppose that the chunks didn't unload, causing them to load into the superflat world with the exact same name. There was a lake in one of the chunks, and in the superflat world it didn't flow over the edge, so I suppose the chunks just didn't unload when deleting and recreating the world in superflat.

I got a screenshot of it.

Confirmed in 1.9. Either this or a related bug. Random chunks relocated upon reloading an existing world.

This is awkward... I thought this was removed...

I'm not sure this is fixable from a developers' standpoint.

The but occurs by deleting a world and making a new one that is named the same thing (as the desc says).

It has to do with the way computers delete things. When a file is deleted, it isn't actually deleted, it's just allowed to be overwritten. So if you create a new world right AFTER deleting one of this same name, it will create the world in the same place on the hard drive, and thus it will pull some chunks from the deleted world.

So that's why it isn't fixable- at least for the developers.

There are workarounds (like 'permanent' deletion), but they are complicated.

Michael Connel, this issue is quite easily fixable, just see my comment made 3 years ago. Granted it is quite awful piece of code, but it was just an example. (I do not expect mojang to solve the issue with that code, it just proves it can be fixed with code.)

The way how some operating systems/file systems delete files has nothing to do with this issue. It has more to do with how minecraft does the deletion, server vs. client architecture, and in some cases too quick exit. Note well the related issue MC-526.

@Deano: This bug is bad, but it's not awful and it doesn't plague us for 4 years or something like that. There is a very simple workaround: Just don't reuse world names, if you create a new world, use a name you didn't used before (append a digit or whatever). Then you should be fine.

I think I know the bug: When you create a world and delete it, Minecraft may not be able to delete some chunk files so when you create a new world with same world name and directory name (in saves folder), it will load the chunks in the folder of the world in the saves folder.

I suggest Minecraft developers that if you create a world, it will have different directory name in the saves folder (like in Pocket Edition).

Lawrence G. you could have read some comments before adding yours, it is quite often useful. E.g. the one just two comments before yours. Or the 8th from the start... Basically, the reasons have been known for years, we're just waiting for the fix.

Does anyone have tips how to reproduce this a bit reliably?

Fabian:
Since this issue is about deleting random left-overs before creating new world into existing directory, it is easy to simulate a situation where the previous world deletion has failed: simply backup random files from a test world before deleting it, delete it, create the directory again if necessary, then copy those backed up random files back into that directory. Create a new world with the same name and compare results, i.e. are the wrong files still in the save directory.

For continued testing, simply store the collection of random files and their world-directory into a zip-file and re-plant them over the deleted world and re-create...

(I didn't test the sequence above, making it up from my memory, but it should give the idea close enough.)

The related MC-526 is much more difficult to test, but luckily this is the more important issue to be fixed and can be tested easily. 3.5 years gone now, plenty of duplicates (more than votes in this issue), nearly trivial to fix and an (somewhat bad) example code given... sigh...

If you put these files in the folder manually, why should they get deleted? I don't see why you should do that except if you want these files there.

Read both this and MC-526 through (comments, too), that should clarify things a little.

You asked for a reliably reproducible test for this issue; putting the files there manually is an easy and reproducible test to check if this issue is fixed or not. (Manually putting the files is like simulating the effect of issue MC-526, which is the typical, but not the only reason for hitting this issue later on.) NOTE: not all the files of an old world, just such a subset that makes the game think the world is not there, yet old wrong chunks gets rendered after new world gets created on top of the remains.

When creating a new world, its files are supposed to go into a very specific (and a new) directory. The directory is not supposed to be there, and if it is, there is supposed to be no files in it. Otherwise the world creation should not be allowed to happen to the name used in the first place. (In fact, one could argue that allowing to name the world in a way that leads to issues is already a bug, but such claim is in the territory that can cause heated discussion among developers about bugs, priorities, right and wrong ways to solve things etc. Lets not continue to there.) But since the world creation is allowed to happen with that name, it is, imho, perfectly fine to assume that if there are any files in the way, they are leftovers of a failed removal, or that they are put there manually by a user, and if a user is putting files in such a place where user's manipulation is not welcome (taking backup needs only copying the whole directory, not individual files inside it), it can be assumed he knows what he is doing and is thus responsible for the fate of those files - the game does not need to account for that kind of messing with its operation.

A really fancy fix for this issue would actually check what kinds of files are there, and only remove the ones that are related to this game, and leave other files as is. I have no idea what other kinds of files users could possibly want to put in there, though... perhaps some sort of README-file or such (though such would likely be needed only when dropping in a full world for playing, and thus world creation is not needed or wanted). But in any case, that kind of fancy change would be way beyond just a bugfix, and belongs to wherever they want the feature requests to be put and forgotten.

I think this is similar to MC-63: The game has to do things after each other and the calculation speed is limited. So if it crashes halfway through saving or deleting, that can't be fixed in all instances. In this case it could delete the folder before creating something or forbid saving in an existing folder, but e.g. in MC-63 there has to be one thing before the other: If it saves the inventory first and then the entites, you can make it crash in between and duplicate items. If it does it the other way around, people who have a crash in between can lose items. One of those two will always happen.
In this case: If you don't allow the process javaw.exe to be killed while deleting a world, you could cause other problems if the world deletion goes into an infinite loop for some reason and the program doesn't want to get quit so that the whole computer lags or whatever.
In short: If a program gets closed from the outside (crash, task manager, ...), it's often impossible to prevent some errors.
(And yes, I've understood now how to reproduce.)

MC-63 is sort of similar to MC-526, not to this. At least the way these two issues are split now (and should stay split). MC-526 is about the failure of deleting after doing that delete-action; this is about failing to clean up the possible left-overs when doing create-action. Possible crashes during creating a new world are much easier to handle, even when there might be something to clean up first.

This issue is more important to fix (and easier, too), because it is indeed pretty much impossible to ensure 100% certain deletion (crashes etc.) Put more simply; fix only this easy one and MC-526 (and other causes) will not matter as much (and won't be seen in the game, only in the filesystem), but if only MC-526 is fixed, there will still be issues caused by other reasons (thus not as often).

(There are still ways to handle the MC-63 sort of properly, i.e. either everything gets saved (pure success) or nothing gets saved-and-later-loaded (pure crash), but it gets quite deep in the coding (somewhat common exercise in business critical systems, though), more than suitable to paste here, should someone even get the motivation to try and do such fixes.)

You can delete the level.dat and level.dat_old of a world folder and recreate a new world under the same name, and then you will get this bug. It's kind of awesome, though, because you can use it to make survival island maps easily. Try making a world using the seed "Flame", with the name "Broken Chunks", exiting, deleting the level.dat and level.dat_old files, and then making the world Flame again, but on a Customized world type where the only biome is Ocean. It's pretty awesome.

1.10, creating a superflat world, then deleting and creating a non-superflat world can "force" villages into weird generations.

1.10,
1. create default world 00000
2. re-create it
3. delete level.dat and level.dat_old from files
4. create superflat world Copy of 00000
5. remakes the original, but only the loaded section. around it is superflat
NOTE: this breaks potions

Please avoid re-editing your comments. Every time you do, an email is sent to those watching this report, which now makes for many emails. I also recommend you set your name to something that isn't blank.

I was playing survival mode on singleplayer, and i went caving in extreme hills, then i got out and all the sudden i saw a huge tower of extreme hills generated in the plains that wasn't there before. there was no lag or relog, it just appeared.

Still present in 1.11

So I've seen this happen a decent number of times. I regularly play hardcore and just use New World to get a random seed. I always delete my old hardcore game when I die, but currently that means telling it once when I die, but that doesn't really delete it, so an additional time selecting it from my game list and then deleting it and confirming the deletion.

If the window between my deleting the old world and the new one is too small I'll often see this bug. Is there really a reason that the delete operation can't just block until it is truly deleted?

Affects 18w21b

@unknown, ticket is yours now

I do not play Java, but it sounds like the instructions are different.
Maybe they are:

1. Make a normal world and write down what you named it (you need it later)

2. Delete the world

3. Quickly create a world with the name you wrote down, but make it Superflat this time

4. Move around quite a bit and you should find chunks from the normal world

Replace superflat with buffet and this happens as well

No, they are exactly the same.

Oh, you meant it the other way around. Yes, you're right.

I am unable to reproduce this in any way. Please add the console log, as well as concrete steps on how to reproduce this issue, as the current provided steps are not sufficient.

I'm unable to replicate this either with the steps that Nathan provided. @unknown are you sure this is still happening? If so please edit the description and specifically the steps to reproduce.

Do read the comments; the reproduction is not deterministic if using only Minecraft (one would need really tight timing and luck), and the reproduction steps in the description are woefully inadequate.

From my memory, from years back, so might not work as is, but... a better process could be:

1. create world with specific name

2. exit game

3. delete certain world save files (enough to make the game think the world is not there), but leave some chunk data files. This manual step simulates effects of world deletion being incomplete (for reason or other, e.g. MC-526).

4. start game again

5. create a new world (random or explicitly different seed) with that same specific name

6. move around to notice chunk issues

Note also the relate issues MC-526 and its comments.

Unable to reproduce with the steps @@unknown has provided, Minecraft always creates a (1) folder instead of using the older with the old files, tested on 1.16

I can confirm the fix. Game now detects existing folders (that do not have complete saved world), and add a counter ( (1), (2), ...) in the end of the directory name when creating a new world with the same old name.

Funny detail: if naming the new world like "name (1)" (i.e. includes the counter in the name) and there is already such directory, game will add another counter, saving to "name (1) (1)".

Even if the bug isn't fixed, per se, as the garbage save data is still left there, the solution fulfills the overall goal of not getting wrong chunks in a new world. I thus consider this issue as good as fixed.

Unable to reproduce in 1.16.1 and 20w27a

Video: https://youtu.be/LMtDccVBYfo

I would think the correct resolution is "fixed", since it was reproduced plenty of times before. "Cannot reproduce" resolution (at least in the meaning I've seen it used usually) basically would mean the issue could not be confirmed by testing at any point (thus not valid issue) 😛, which obviously isn't the case here.  Yeah, yeah, I'm nitpicking, while happy it has been fixed. Finally.

If you are able to provide the game version upon which this was fixed, I can try to update accordingly.

It has always been the normal thing to just pick any reasonable version then. "Cannot reproduce" is simply false. It also suggests that people are supposed to try to reproduce it, which would just waste time in this case.

Policies can change.

If we just pick any random version as fix version, it's a false statement as well. Nevertheless, this is not the place to discuss that.