nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

As we transition to the new Hyland Community, some post links may be temporarily disrupted as we finalize redirects. We apologize for the inconvenience and are working to resolve this as quickly as possible. Details.

Case insensitive document names

smcardle

Hi All.

I am trying to upload some documents from my Linux machine using drag 'n' drop in Share.

In the list of files I am uploading are 2 files named README.TXT and README.txt. However, Alfresco renames one of these as README-1.TXT or README-1.txt depending on which one got uploaded first.

Is there anyway in Alfresco to enable case-insensitive Document names as supported on Linux file systems such that the documents retain their original names ?

Regards

Steve

Find more posts tagged with

Comments

afaust

Hello,

unfortunately, I don't see an option to have Alfresco treat file names as case-sensitive, i.e. not treat README.TXT and README.txt as the same filename. Alfresco needs to support the least common approach to handling files and unfortunately, due to the prevalence of the monstrosities that are Microsoft software products, it has to err on the side of caution. The lower-cased comparison of file names is implemented in a low-level component, which would not allow for a case-by-case evaluation / handling.

Regards
Axel

smcardle

Hi Axel

Thanks for the response but I can't believe this is true.

Alfresco stores document names in metadata in a database, not on the file system. The filesystem contains <UUID>.bin files. So where is the issue with lowest common denominator for case-insensitive file names ?

Regards

Steve

afaust

Hello,

this has nothing to do with how Alfresco stores its content / metadata - Alfresco could handle case-sensitive names as a database-based application. It is more a constraint due to the clients it has to support via CIFS / WebDAV et al - at least that's what I reckon. There could also be some constraints imposed by other components, i.e. index handling, that require an insensitive approach.
Nevertheless, the code that is responsible for the renaming in your case checks wether a file with the same name already exists in the given folder and does so by comparing the lower-cased name of the file with lower-cased names in the database. This is done at a core component level common to all API services.

Regards
Axel

mrogers

Yes, the repository is fundamentally "case sensitive" in that it persists the specified case and many of the fundamental methods are case sensitive. However there's quite a lot of features and protocols that would not work with multiple file paths identical except for case, so its a whole lot easier just to prevent this confusion in the first place. You could use your own models or turn off the unique constraint for file/folders if you really want to, if for example you have a custom application on an embedded alfresco repository, however there would be a lot of fall out.

smcardle

Thanks guys.

That kind of makes sense regarding CIFS and it's absolutely not possible for me to change the repository behavior either.

So tell me, how is the Alfresco desktop synchroniser supposed to work if it's installed on a FileSystem that DOES allow files to differ by case only? (such as OSX and Linux FileSystems).

Would this not result in a ping-pong between the repository and the file system as they can never be considered synchronised ? With the repository creating a fake file on the FileSystem such as README-1.txt …

Steve

mrogers

The rename functionality is part of the share drag and drop. It's not core repo behaviour.

However its a good point that use-cases like that need testing.

thijslemmens

The problem is worse when you get case differences in the folder structure.

We wrote an import tool that communicates using the old webservices API. It automatically creates the folder structure. It used to fail if there was a path existed with a difference in case. An XPath check would fail because it was not exactly the same, but the folder could not be made.
We solved it by using case insensitive lucene searches recursively, but it is quit expensive. It would be nicer if there existed a case insensitive path check.

kind regards

Thijs Lemmens