For "abstract" views, the GDS_FILE property is supposed to point to a valid GDS file containing the definition of the cell. This makes sense for cells like the SRAM but even for standard cells, where some layers (e.g., the implants, or the ones that magic wants to generate automatically, and are not drawn or displayed as user-editable layers) may be drawn in a way that magic would not reproduce exactly. The general rule is: If the original GDS is known good and was carefully manipulated by hand for correct DRC, then it is probably best to have it as an abstract view. If magic generated the cell, then there's not much point in using the abstract view, since magic would just generate the same thing any time you write GDS from it. If you have an abstract view, but the GDS file gets put somewhere else, or the layout gets put somewhere else and the GDS_FILE is a relative pathname, then the GDS file won't be found, and magic will resort to trying to generate GDS from its own view. Which might be fine. . . or might be disasterous (as it would be if you did that with the SRAM core cell). If you have a cell generated by magic, but somebody wrote GDS from it and then read GDS back in with the "readonly true" option, then it will have the unnecessary GDS metadata, and removing them is the better solution. You can do this from a script with the magic commands like
property GDS_FILE ""
. Or just manually delete the properties from the .mag file.