The original scenes were numbered sequentially. Sceneview1, Sceneview2, etc. This feature was lost somewhere. As far as I am concerned, it should be restores. The name of the sceneview is used as the name of the thumbnail and use of the same name can lead to overwriting a thumbnail.

Csaba, how do you create nodes with the same name? If you just data from a file Slicer should add _1 to the second node with the same name. Do you create the nodes programmatically?

Yes, I create volume, model and color nodes in the DicomRtImport module, when loading data from the DICOM database to Slicer. When I load the same series twice, then their names are the same.

I could call vtkMRMLScene::GenerateUniqueName, but without explicitly calling it, the names remain the same. If there is really no use case when objects with same names are required (in my case it is not required, but I cannot see the need of every user), then the GenerateUniqueName function should be called when setting the name of a node.

I cannot think why would vtkMRMLNode::SetName() not do that, but lets discuss it at slicer hangout.

As discussed on the hangout, we unique names in the user interface shouldn't be enforced, but unique file names should be.

Alex will be looking at centralizing the handling of unique filenames as part of issue 0002816.

After discussing this issue with Steve there are somewhat conflicting requirements of keeping file names in sync with Storable node names and keeping file names unique. There are different use cases, and the logic of satisfying both requirements becomes complicated.
Csaba, it seems that what you really want if for DICOM import to create unique names. Would that satisfy your use case?

There are many possible workarounds for this issue, there is no question about that.
The point here is that

1. MRML nodes having the same name is allowed
2. Files having the same names are not allowed
   These two are in conflict, thus there is a bug when saving a scene where the same name appears in more than one MRML node.
   I think the correct solution would be to ensure unique names for MRML nodes in general. Is there an advantage in allowing duplicate MRML node names?

It seems like we need to discuss enforcing unique MRML names.

Why not just add a validator step to the save dialog? It seems that if we found that this issue existed we could put up a simple table where every filename is made unique. Then let the user edit them if they don't like them. This should include scene views.

Another thing we might consider: if the nodes with the same names are in different parts of the subject hierarchy they could be created in corresponding subdirectories on disk (or given names that concatenate the hierarchy name with the node name). We could also prefix with the sceneview name.

I like the idea of different subdirs basd on major hierarchy branches, but it's not something we can implement now.

Is there an advantage in allowing duplicate MRML node names in the scene?

The only advantage of duplicate names would be exactly in the hierarchy case (I thinnk preop/kidney and postop/kidney is better than preop/kidney and postop/kidney_1). Also we've never ruled it out before so some code could break if we start insisting on uniqueness.

OK, the subdirectories and the reconciliation table (in case there is a duplication within a directory) sound good.
Thanks!

I think for now when there is a filename conflict we should just show an error popup to inform the user and reject the saving (and let the user resolve the conflict manually and retry the saving).

Later, if we have time, we could implement a "Resolve" button in the error popup, which would call an algorithm that would generate unique filenames by adding a prefix based on names of parent hierarchy nodes and/or adding some generic postfixes (_1, _2, ...).

I agree - the biggest issue now is that the save is half-finished before the user is notified. They can still re-save and fix the paths, but it's awkward.

Since it is late in the release and the logic for enforcing unique names is not crystal clear, moving to 4.5

I confirm this is still an issue with r25435

Step to reproduce:

• Load MRHead
• Apply Gaussian blue creating a new volume as output
• Rename the output to have the same name
• Save
• Reload
• Both MRHead are identical ... whereas we could expect to have both loaded