Hello guys
We migrated a client today, after reviewing manuals 7.9 to 8.0, and 7.9 to 8.1 to make a perfect preparation.
Unfortunately we found out exactly the consequence bug-13518, not being prepared to that (and had to modify a hell of links).
To be precise, we had entire architecture of ressources of all windows starting with “CON” as main folder (an abbreviation)… bad luck… (because of renaming entire app needs had to be modified).
Maybe would be great to add some comments in the migration manuals:
“Because of moving from internal database to filesystem, some ressource names that were previously authorized could be renamed during the migration”
Also could be good to write rules for naming windows etc… in 8.0+ documentation ?
Finally one thing I do not understand, is that this applies to windows only, and on linux things are very different. We are on linux 100% and should not be impacted at all.
What about a bugfix of the bugfix ?
Implement "do not authorize ressources that are matching the reserved keywords of the filesystem"
instead of “do not authorize ressources which filenames are matching reserved keyword of DOS/Windows filesystem” ?
Of course this would require checking at each gwbk restore, but I think this process is already in place (a bit too aggressive imho) 
regards
While CON etc are not reserved words on Linux, we felt that it was the lesser of two evils to prevent those names on all platforms, to prevent a scenario where a .gwbk from a Linux system could not properly restore on a Windows system, or vice versa.
While it’s officially discouraged, if you don’t need to restore to another system, you could just rename the files on disk, which will rename the resources - we literally can’t prevent you from doing this, so if you do so outside the context of a project import/gwbk restore, we don’t try to stop you.
Smiling when I read the answer… Thanks for the update.
Interesting hack
Would it be “scalable” on long run ?
IE If we would restore a 8.1.0 backup (with names hacked) on 8.1.1 gateway would the process of file name checking would still apply & try to fix names again ?
IE if we try to save a window which name has been “hacked” will designer accept ?
thanks
Any restore operation (of the project, or a .gwbk) will trigger the code path that overwrites the name - it’ll only be ‘safe’ to upgrade the one gateway in place. Backups will be intact - they’ll just restore with unique file names. You would still be able to ‘hack’ a backup into place - it’s just a .zip file, so you could restore the backup (to get configuration, tags, etc) and then copy the project directories from the .gwbk over the target’s filesystem.
As for the designer, I think saving resources with illegal names should work, but any attempt to rename will require moving to a valid name, and there may be other gotchas in individual modules.