Minecraft server appears to presume a case-insensitive filesystem (Windows, most OSX)
For player data storage on Linux, this has the following observed effects in the /<worldname>/players/ directory where the <player>.dat files are stored:
for offline players, name Foo is distinct from foo and are thus separate players.
for players with a Mojang account, account name Bar as example: somewhere the server lowercases the name before save so it stores bar.dat, but most of the time it uses Bar.dat - this is indicated by the fact that both are created but Bar.dat tends to have the most recent timestamp.
My suggestion for fixing all this, without breaking existing environments (presuming only the two above behaviour patterns exist, I am not aware of others)....
logic flow (in pseudocode) as follows:
On login
if exists (Bar.dat) {
read Bar.dat
write bar.dat
delete Bar.dat
}
else if exists (bar.dat) {
read bar.dat
}
...
always write bar.dat
So after transition, the server always uses lowercase(name) for filesystem operations.
This should provide a safe transition.
Comments 7
Is this still a concern in the current Minecraft version *14w11b / Launcher version 1.3.11 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
As an experienced programmer and project manager, I feel a tad frustrated by the frequent "is this still an issue in this new version" questions. It essentially means that all bugs become invalidated when a new version is released, and everybody has to reconfirm the previously reported bugs.
That seems like a very inefficient way of bug report handling, and also seriously discourages user feedback - the latter is of course vital for the continued success of a software product.
Here is my suggestion:
Basically, unless something has been changed in related code, a bug should remain valid.
Since you'll have detailed change tracking internally, you'll know when this is not the case, and then it's indeed good to ask users to re-verify.
Dear Mods - do you have any reason to believe that the bug may no longer exist in the current version?
The mods are volunteers, with no access to the original source code, Mojang's internal repository, logs, etc. Unless one of the developers themselves takes interest in a particular issue, and marks it as fixed themselves, the only way the mods have to know whether or not a bug has been fixed is for someone to test it.
I don't like the frequent emails about whether or not an issue is still active, so I fixed that by creating an email filter. But their behavior does suggest that they prioritize closing issue reports over the bugs actually getting fixed.
The whole thing is definitely very inefficient. The problem is one of volume. How many companies, or even individual products, do you know of that have user-accessible bug trackers? A substantial portion of the issues on this tracker should never have been entered, because they're invalid, duplicate, etc. Fundamentally, the bug tracker software is too complicated for most users, and they don't have the patience to properly research their issue and present it correctly. They just want a place to complain, and receive personal attention for their problems. In short, they treat the bug tracker like a technical support system. So at some level, I could see discouraging user feedback as a valid goal.
Ok, I understand (didn't know before) about the mods not being Mojang employees.
Discouraging user feedback is throwing out the baby with the bathwater.
If people just want to know how to do something or want to have a whinge, then providing appropriate public facilities for that will discourage other tools (such as JIRA) from getting used for that purpose - because indeed JIRA is definitely a bit higher end.
However, people who are serious about providing real bug reports will probably have sufficient experience to deal with the JIRA interface, as it's not that different from Bugzilla, Launchpad and other systems.
In terms of volume, I have experience with a large number of companies and products that have public bugtrackers - the reason for that is that those are Open Source projects. So you can think about OpenOffice/LibreOffice, Mozilla Firefox and Thunderbird, and so on. Various Linux distributions (Ubuntu, for example).
All very substantial and sure many bugreports are not "real", and it's fantastic when people from the community help, that's in fact how all these products make the system work. The people help out because they realise it's critical for the quality of the product, so by helping others and the project they help themselves as well. It's a complete win.
I'm not petitioning Mojang to make Minecraft open source, that's not the issue here and it's entirely their choice. Even for closed source, some form of the "raw" changelog (just the commit msgs) could be made available for the moderators, that would provide a very good guide. A bugfix tends to reference the bug#s it fixes.
So in summary, I don't think the fundamental problem is volume, it's process. Others do more volume so it's definitely possible. The challenge is to figure out how to do it in a non-opensource environment. I think it can be done.
I'm happy to provide bugreports, and some of mine have been pretty detailed - should give the developers a good angle on where to look. But I do feel the need to then be taken seriously, and not have to re-tag the same issue or see it be closed without resolution.
I reckon that experienced moderators can distinguish between a whinge and a serious bugreport. That filter is a human one, and unavoidable.
Also, Mojang devs themselves can do their thing here so it doesn't have to be all just moderators.
Is this still a concern in the current Minecraft version 14w21b / Launcher version 1.4.4 or later? If so, please update the affected versions in order to best aid Mojang ensuring bugs are still valid in the latest releases/pre-releases.
It's still valid in 1.6.2.