Renaming Identifiers Recommendation

[Jake]

Now I realize again that this is probably my fault for changing my identifiers too fast, but this could easily be used to cause grief to a customer.

Say a customer used their managed panel to rename their identifier from x to y, but immediately after they start the rename, another customer registers a new server with an identifier of x. This would cause the customer that just renamed their identifier to y to loose all their data and they would be stuck with a stock server. I just did this with my server, but I always keep backups so it's no big deal to me, but I think this feature should have a few more fail-safes in place to prevent these types of things from happening.

Also just realized that this will break FTP and a few other things. I probably have to open a support topic now.

[kraze]

I'm not following you when you say lose all your data. Identifier renames don't effect your server files. Your situation is also not something that really comes up. Due to the nature of identifiers users generally don't choose common ones, most are an abbreviation of a clan name and game. There also isn't a real way of knowing when an identifier is changed. Which means a case like this generally wouldn't be random and would be planned out with the current identifier owner.

[Jake]

I had 3 servers with clan name identifiers like so
sgjb1
sgjb2
sgjb3

Then I wanted to bump sgjb2 up and put another server in it's place, so I renamed sgjb3 to sgjb4, sgjb2 to sgjb3, and then made a new server called sg2. I'm assuming since the files are copied from the directory for sgjb2 to sgjb3 and sgjb3 to sgjb4, that creating the new server over-rode and removed those files. I can understand that such a situation would be extremely rare, but I guess it's still possible

[Jake]

I should have remembered from last time not to do this, now the ftps are all thrown around and it's all glitchy. Probably going to have to get John again for this one.

[kraze]

Either way, your files aren't gone. The only thing that changed was the identifier. Your files are still there and active, the ID is just different.

Unless I'm misunderstanding you?

[Jake]

Well, I've done this once before and you guys had to get John involved.

What I did was I started an identifier change, then I made a new server with the same identifier as the old identifier.

From the best of my knowledge, the files that were going to be copied from a were replaced by vanilla server files, this also somehow causes the FTP information not to be passed to the new identifier, I keep receiving access denied while trying to ftp into any of the servers, I think if I used the old identifier and the old password, it would probably work, but I haven't tested it.

[kraze]

If you are talking about doing those processes simultaneously, than yes, I could see that causing issues. When an identifier is renamed your are essentially creating a new server and restoring from a fresh backup, so it can take a few minutes depending on the overall size of your server. You definitely want to allow time in between those renames.

[Jake]

Well, that was what my recommendation was, for NFO to add some kinda timer to prevent customers from being able to do that, even thought it is obvious that you shouldn't do it.

Is it even possible to get backups now that I've done that? I started working on a new project and lost all the work there. It wouldn't be that big of a deal to replicate, but it might take me a while to do again. Either way, I need my servers repaired now. Should I open a help request ticket?

[Jake]

Fixed already, nice! I may have made your job harder by trying to fix it myself by renaming them all again. Whoops. As long as all the servers and all my FTPs work, I will be content.

You can perform at most one rename operation per hour.

[kraze]

That is a precaution that has been in place for awhile.

[Edge100x]

If you don't overlap renames by having one server renamed into another and a second server renamed to the first happening at the same time, you'll be fine.