Content Manager EE supports multiple items that use the same file name or label within the same parent folder.
Depending on the application, the application might check for existence of an item before creating an item. The application might report an application error or prompt the user to replace the item if one with same name exists. The repository allows multiple items in the same folder to use the same name depending on whether the item type configuration is hierarchical or not. IBM® CMIS for Content Manager adds unique name enforcement for all item types within a folder regardless of item type configuration if path indexing is enabled. The data created or modified by other applications, created without path indexing, or existing data can have the same names when not restricted by the repository. IBM CMIS for Content Manager supports existing data in the repository with the same name by generating a unique path to each item with the same name that works with most applications. When path indexing is enabled, the existing name value is reported with a slightly altered name and is saved if the document or folder is modified.
For repository data found with same name values, the name and path are reported slightly differently depending on the following conditions:
When path indexing is enabled, existing data and data from other applications that is indexed by the path index crawler are supported by adding a parentheses with a sequential copy number to the file name or folder name. When folder operations or queries are optimized by path indexing, the results are filtered or sorted according to the augmented name and path value instead of the original name. When you save the changes, the augmented name value is saved to the document or folder as the new name value. The users can still change the name to any unique value. When you create or modify documents or folders through IBM CMIS for Content Manager, duplicate names are not allowed.
For fast paths, IBM CMIS for Content Manager generates a unique ID and unique path for each item.
The fast access paths that are generated by using composite names (rather than just the non-unique label) provide for a unique path, but the fast path still reports the label (file name) and title as they were submitted for the application to show to the user. If you disable fast paths, you do not get the performance and scaling benefits of fast paths. In addition, if you disable fast paths, the generated paths might not be unique because they use only labels (names) instead of the composite information. Accessing items by a non-unique path results in an error if the unrevised path resolves to more than one matching item.
With fast access paths and path indexing disabled, the repository supports creation of multiple items with the same label. However, the application might detect the existing item by path before creating one with the same name and instead prompt the user.
Two users with different permissions might be able to create items with the same name and not have a problem. However, a third user who has permissions to see both items cannot access them by a non-unique path unless unique fast access paths are enabled.
If you try to open an item when multiple items exist in the same parent folder with the same name, then depending on the application, you might receive an error reporting that multiple items exist with the same name and the path submitted cannot uniquely identify which one of the same-named items you want to open. If the application uses the actual path returned for each individual item, including composite names, then the path uniquely identifies which item you selected. If you receive this error, refresh your folder view. Then, retrieve the folder contents list with valid unique paths for each item.
For example, with some client applications, you can create multiple copies of the same folder if you create or drag the same named folder multiple times. However, you cannot open any of the new copies until you refresh your folder view because the application does not track the path that uniquely identifies the item until you refresh.
As mentioned previously, not all applications handle same-named or same labeled items within the same folder. For example, the application might depend on the label (or file name) field rather than the generated unique path and ID. Applications are expected to gracefully handle multiple items with the same name or label, so that the application does not fail. It is up to the application to determine its handling. Some applications might show of the all same-named items and internally map them by using the unique path or ID. Other applications might filter out duplicate names and show only one. If the application accesses the remaining items by ID or true unique path, you might be able to use the items. However, if the application attempts to access them without using the generated unique path or ID, you get an error indicating that the path does not uniquely identify a single item.
For example, some client applications handle same-named items that exist, and allow you to access each separately.