Affects Version/s: 6.2.10 EE GA1, 7.0.0 M3
There is an inconsistency on how we validate files at creation time in the DM. This inconsistency causes that some DLFileEntries are no longer editable, can break staging and makes Liferay Sync to overwrite files
When the title of a new file entry does not contain extension, we look for the existence of an entry having the same title + ".<extension>" (where <extension> is obtained from the original file being uploaded). In case we find such an entry in the same folder, we throw a DuplicateFileException. This could happen, for instance, if we upload a file and specify a title without extension.
This allows DM to work with Liferay Sync. That behavior was introduced in
But when we upload a file and don't specify a title, we don't check the existence of an entry having the title w/o extension and the stored extension equal to the one being provided.
As a result, we have an inconsistency beween the 2 following cases. Please note that they just differ in the step order:
1. Upload a file called "image.png", specifying "image" in the title
2. Upload again the same file in the same folder, don't specify title.
Result: portal allows to do the step 2 without error.
1. Upload a file called "image.png", don't specify title.
2. Upload again the same file in the same folder, specifying "image" in the title
Result: portal doesn't allow to run the step 2, as the DuplicateFileException is thrown
There are some problems if we allow case A) to happen:
- The file entry uploaded in step 2 is no longer editable. Any attempt to publish changes will fail as long as the title remains the same.
- It can break "publish to live" function. The reason is that there is no way to control the import order. Therefore, in staging, we can have case A but when publishing, the process may flip import order and we can end up having case B, which creates a non-recoverable error in the publishing process, aborting it.
- In addition, Liferay Sync would download both files to the same location.
The root cause of the issue comes from the fact that DM stores the title and the extension separately. In turn, title can contain an extension as well. In addition, when uploading a file through the portal web interface, there is a "source file name" which contains the name of the uploaded file on disk. Finally, the DLEntry title that is stored in the DB can also be specified by the user or, if none is set, it will be equal to the source file name.
Therefore, after case A, we have the following data in the DLFileEntry table:
This is because, when uploading the file (case A, step 1) sourceFileName contains the extension and title doesn't. As a result, DM gets the extension from the source file name.
Please note that this is a different case from not having extension in the source file name. In that case, step 1 would upload a file with no extension in the local file system, and we'd end up having:
This is not the case we're dealing with. Common filesystems allows to have two files with same name and different extensions (including no extension).
Because of our distinction between sourceFileName and title, we have case A which wouldn't ever happen in a regular file system.
Please also note that current validation does not allow to have two entries with the same title. Therefore, following case is already forbidden:
This ticket is specifically devoted to deal with case A described above.
Case A has to be avoided.
The constraint that any folder must enforce is there can't be two DLFile entries a and b such that:
- a and b have the same extension
- a's title does not contain extension
- b's title has extension, and after stripping it, it's equal to a's title