I've mostly encountered errors with file name max length issues when there's a discrepancy between what Windows allows, and what M-Files allows.
TBH - I'm fuzzy on the exact details, but users will run into this, if they've drilled in several layers into many sub-views, and then one top of it, they want to open a file within a multi-file, both of which have very long file names.
You'll also note when migrating, if the file name is beyond 256 - M-Files will alert and truncate the file name. Somewhat annoying at times.... however, I think it also speaks to the larger principle that users should keep their names structured and accompany with logical properties.
If the document is related to a Committee for example - tag the Committee Object and avoid the legacy of typing the committee name into every. single. document. name.
I've been trying to work this out for ages. A couple of days ago I did some research and this is what I found.
This will be quite long as I was going to post this separately but might as well be here.
Some history:
We have an annoying file system where documents from one division still are stored on a windows server drive and are imported (linked) to M-Files to have them populated with metadata with various scripts.
We've enabled the option that's in Joonas' link, which hasn't solved anything. I've just been to busy to try and research this further.
As ssential has said, it truncates the file name, and when it's importing, creates errors as it tries to constantly import the longer file name, but cant due to the length, then truncates it - but the truncated file is already there. If that makes sense.
As a result, many files on our server aren't moved across.
But I don't believe the 260 limit is the case. I instead thing the length of the file name (not including the folders) maximum length (not including file type extension, i.e. ".pdf") is 100 characters.
Here is a real example that I've seen just now (causing a critial error in the event log) - everything has been randomized for security, but the string lengths are the same in the same format:
Processing the contents of the external source "2019 (\OURSRV1\Fold\2019)" failed. Processing of the source file "\OURSRV1\Fold\2019\xx-xxxx\Workxxxx documentation\ABC1234 XXXX - XX - XXX ABCEIT Street IRUEHWAYER JSU 8272 - AA Prohyws abc 123 - abcD - ORDER ? JS82JS8J AUDIT.pdf" failed. Updating the external link of the file "ABC1234 XXXX - XX - XXX ABCEIT Street IRUEHWAYER JSU 8272 - AA Prohyws abc 123 - abcD - ORDER ? JS82.pdf" failed. Adding the linked file failed. File "\OURSRV1\Fold\2019\xx-xxxx\Workxxxx documentation\ABC1234 XXXX - XX - XXX ABCEIT Street IRUEHWAYER JSU 8272 - AA Prohyws abc 123 - abcD - ORDER ? JS82.pdf" already exists.
The original file & path length (starting from \OURSERV1.....) as in our windows server is 165 Characters Long
The original file name length itself (not including folders) is 114 characters long.
It then truncates the file and path length to one that is 155 characters long - or a file name that is 104 characters long.....
If the M-Files file length is based on the traditional folder length as viewed in M-Files, so the "\OURSRV1\Fold\2019" is replaced with "M:\OUR M-Files\Fold\2019", the string length is only five characters longer, resulting in the above total lengths being changed to 170 and 160 characters respectively.
There are about 20 other examples that I've looked at on our event log.
All of which have total file lengths no longer than 104 characters including the ".pdf" - or a length of 100.
I've also deleted the "f" off ".pdf" and low and behold it truncated the name to 100 characters.
100 characters is also the maximum length of a single line text property, which "Name or title" is.
I've also tried setting the name/tile based on a multi-text property, but this simply gets cut to 100 characters again.
So to answer your question, the longest file name you can have in a folder is 100.
There are problems in some cases if the path + filename together are longer than around 255 characters. I believe Windows sees the Views as folders and handles them as part of the path. You can reduce the view names to help keep the path relatively short.
You are correct in that the 'Name or title' is limited to 100 characters as are all single line text fields. Also the default total limit of the Path + Name is around 260 characters unless the previous Windows fix is applied for this. This would the total length of the name + vault name + search/view path.
The Windows path fix will increase the total length it can be for each computer the fix is applied for but does not increase the 100 character limit for the title.
There is a sort of workaround, in that you can force a multi-line text field to be a single line which increases the text field limit to 10k characters.
This can't be used on 'Name or title' as that's a built in property but you can create a new text property 'Long Name' or similar and apply the fix to that property and then set that to be the name field used for the class(es) as needed.
This won't fix the import truncation issue when it's looking at duplicates but should hopefully give you some more flexibility.
