why matlab won't support file name length more than 63 char?
Show older comments
Is there any limitations with respect to operating system, controllers or anything?
Please can someone explain me clearly what could be the possible reason?
1 Comment
Henric Rydén
on 22 Jun 2015
I have never heard of this issue. I tried creating a folder with 115 characters in it and it worked.
Accepted Answer
No, Matlab supports longer file names. Some commands are limited by the file system, e.g. deleteinmg files to the recycle bin under Windows suffers from the horrible limit of 260 characters for the path name. But for a simple file copy etc. wide names are accepted, which allows 32767 characters. (Please feel free to send a letter to Bill Gates and ask him, why the 260 characters limit is still prsent in teh 2015'th Windows 10.)
Under Linux/MacOS long file names are supported in general.
But the names of variables are limitd to 63 characters. Perhaps this is your question. This limit is useful, because longer names for variables are ridiculous and cannot be read or debugged anymore. Such long names are a secure hint, that the programmer hides information in the name of the variable. But such information should be found in the data, in the values of the variables, e.g. by using structs with an extra field for these information.
As the names of variables, the names of functions are limitted als for the same reason.
Beside the readability and the idea of smart code design, the symbols can be managed more efficiently, if the length of the names is limited. E.g. the fieldnames of a struct can be stored in blocks of a fixed width: For each fieldname 64 bytes are reserved (63 characters plus a trailing \0). This allows to find the n'th field name without considering the lengths of the former n-1.th names. In consequence the lookup tables for finding variables in the workspace or fields in a struct can be processed faster, when the length of the names is limited.
The limit was 31 characters until Matlab 5.3.
20 Comments
@gvreddy: can you please give us a link to the documentation where you are quoting this from? A [search engine name] search for that string (or significant parts of it) it locates only this question, but nothing in the official documentation, which implies that the source is a 3rd-party toolbox.
What is the code that you are running? What is the function (or toolbox) called? Please show us exactly what you are calling that generates that warning message.
N/A
on 22 Jun 2015
We can check MATLAB very easily, here is a filename with 104 characters (+ extension):
>> X = 1;
>> S = repmat('A':'Z',1,4)
>> save(S,'X') % no warning or error!
>> numel(S)
ans =
104
And yes, the file is generated correctly. So, no filename length limit of 63 in MATLAB then (tested on R2012b).
It seems that you are using a 3rd-party tool (i.e not part of MATLAB distribution), which has a restriction on the filename length. You will not tell us what the tool is, nor how it is used, and we don't get to see the documentation either. You will have to contact the people responsible for this tool and ask them.
Sure, but it is not clear what you are calling, or what tools you are using, or indeed what functions you might be using. It sounds like a problem in a third-party tool, especially as that text that you quote does not seem to come from any searchable documentation.
Adam
on 22 Jun 2015
I have hit this limitation for certain file and function names, but not with that error message. Obviously you would never usually want a file (excluding the directory path) or function name that long, but when writing a unit test framework I often want test names that are long an explicit to what scenario they are testing.
A .m file or a function name carries that limit, but not general file access that I am aware of.
N/A
on 22 Jun 2015
I understood that variables, functions have limitations on name length. I will not create any function or file name with larger name(>63 char). But I have to check if there any such file.
For testing, I have created .slx and .m file names with 65 char. When I try to open .slx file, I am facing error:
and .m file is fucntion with name of 65 char. Inside function, I have just defined var = 1. that's it. When I run the file, I have facing mentioned warining in above post.
Adam
on 22 Jun 2015
How are you opening the file?
Walter Roberson
on 22 Jun 2015
If you have to check if there is such a file, you can use fileparts() and length()
Guillaume
on 22 Jun 2015
I can confirm that gvreddy problem is indeed with matlab. With R2015a, on Win7 x64, you get a warning if you try to rename a .m file to, for example, file21234567890098765432123456789009876543212345678900987654321as.m in the matlab file browser.
Matlab also fails to open a simulink model that has been renamed in the OS file explorer to file21234567890098765432123456789009876543212345678900987654321as.slx with the error stated.
There are indeed restriction on the length of filename in matlab. They may very well not be documented. Mathworks is particularly bad at documenting the limitations of their code.
N/A
on 22 Jun 2015
Image Analyst
on 22 Jun 2015
Renaming the file works just fine for me with the same system as Guillaume:
destinationFilename = 'file21234567890098765432123456789009876543212345678900987654321as.m '
sourceFileName = 'test1.m';
movefile(sourceFileName, destinationFilename);
Also, double clicking on the new filename in the Current Folder panel opens it up in the editor just fine. Not sure why it's not working for others.
However there are some limitations with other programs, like Excel has a 218 character full file name limit.
Guillaume
on 22 Jun 2015
Image Analyst, yes renaming the file programmatically work fine. But in the current folder panel, if you try to rename the file (press F2) then you get a warning.
Ganesh Hegade
on 10 Nov 2016
@Jan or @Image Analyst
I need some details about this restriction related to Simulink Diagram. I have a filename with more than 63 char and trying to create a simulink system with same name. But its giving exception
new_system('MyProject_CreateLocalAndGlobalCoordDataFromMeasurementAnimate_Model.slx')
Error using new_system
The name
'MyProject_CreateLocalAndGlobalCoordDataFromMeasurementAnimate_Model.slx' is
not valid because it has more than 63 characters.
This limit is applicable for Simulink DIagram too ?
Steven Lord
on 10 Nov 2016
According to the description of the 'name' input argument on the documentation page for new_system, yes this limit applies to model names.
Walter Roberson
on 10 Nov 2016
Yes, system names must be MATLAB identifiers. Simulink models are callable by name in MATLAB so they have to meet the identifier requirements
David J. Mack
on 10 Oct 2022
I disagree with the "are ridiculous and cannot be read" part. When writing unittests it is utterly important to make them self-explanatory. A usual naming scheme consists of three parts - the name of the unit-under-test (aka function), the precondition (what am I doing?) and the expected results (what is supposed to happen; not the same as what is supposed to be returned!). In this case, you often have longer names, which are actually very helpful for understanding & debugging. And the length limitation actually enforcers developers to make shortened names which often end-up being so cryptic, that you cannot really derive anything from it.
So yes, make variable names that long might not make too much sense. But for functions this isn't true.
More Answers (1)
Steven Lord
on 22 Jun 2015
2 votes
If you want to create a MAT-file with an extremely long name you can do that, as MAT-file names is not one of the categories listed in that documentation. If you want to create a variable or a script file with an extremely long name, you will receive a warning and the name will be truncated.
I agree with Jan's assessment -- if you are trying to create a variable with a 70, 80 character name you're probably trying to encode some information in it that is more appropriate to store as data rather than as part of the name. For that I'd consider a separate variable or storing the two pieces of data in a struct array.
8 Comments
M R
on 6 Dec 2017
One problem with this is that the 63 chrachter limit, as of r2016a, appears to apply to scripts as well.
Best practices for record keeping in digital lab notebooks suggests maintaining dates and identifying information in the filename, in order to clearly organize records of past work in a way that can be searched via the filesystem.
By forbidding scripts from having long names, Mathworks is limiting the usability of Matlab for exploratory data analysis, as it impedes detailed record keeping of past commands in script files.
Mind you, my use case doesn't require absurdly long file names, just on the order of 100 characters or so. Truncating the name will cause incompatibility with records elsewhere in the data processing pipeline, and is simply not an option.
Steven Lord
on 6 Dec 2017
Yes, this limit applies to script file names, function file names, class names, method names, variable names, struct array field names, etc. As far as I'm aware it has for at least the past 16 years, though the limit on the identifier length has increased once during my tenure at MathWorks.
I did a quick Google search for best practices for lab notebooks and none of the half dozen or so hits I found recommended storing metadata in the file name. Could you post a link to a best practices document in which that recommendation appears?
You mention "Truncating the name will cause incompatibility with records elsewhere in the data processing pipeline" -- can you say a bit more about your data processing pipeline? Are you using some other software package that recommends or requires files to be named in a particular format?
KAE
on 1 Aug 2018
Here is an example of hitting the mfile name length limit, intended to show that it can legitimately be a hindrance. I got this error on R2018a in Windows 10 when I was trying to run a mfile with a long name, and the name was truncated. The long name was convenient because I had many different versions of a similar mfile in the same folder, each intended for a different treatment of some data. I kept finding something different that the program had to do with the data, and the mfile name was a convenient way to indicate what aspect of the data I was looking at.
Steven Lord
on 1 Aug 2018
The long name was convenient because I had many different versions of a similar mfile in the same folder, each intended for a different treatment of some data.
Can you give an example of this? Are your files named something like "processDataSetForPatients_operateOnName", "processDataSetForPatients_operateOnWeight", "processDataSetForPatients_operateOnHeight", etc.?
How similar are those "similar mfile" scripts, functions, or classes? If they're the same except for say the name of a field in your data on which they operate, I recommend unifying them into one function that accepts the name of the field on which to operate as data instead of including that information as metadata stored in the name of the program.
I kept finding something different that the program had to do with the data, and the mfile name was a convenient way to indicate what aspect of the data I was looking at.
I still suspect there is a different way of organizing your scripts / functions / classes that avoids needing to use a file name longer than 63 characters.
One such option is packages; the fully qualified name of a package function can be longer than 63 characters so long as neither the package name nor the name of the function inside the package exceeds 63 characters. I just made a package function whose fully qualified name is 83 characters long and I was able to call it. [It adds its inputs together.]
>> length('abcdefghijklmnopqrstuvwxyz.abcdefghijklmnopqrstuvwxyz.sampleAlphabetPackageFunction')
ans =
83
>> z = abcdefghijklmnopqrstuvwxyz.abcdefghijklmnopqrstuvwxyz.sampleAlphabetPackageFunction(1, 2)
z =
3
How similar are those "similar mfile" scripts, functions, or classes?
80% of the code lines might be the same. In each, I am changing algorithms and aspects of the data that I use. It is ugly trial and error code not meant to share with anyone else; once I figure out what works, it might make sense to clean it up. I need to retain the 'error' code because I need to keep track of what didn't work, so I don't try it again later.
One such option is packages
Can you give an example of this?
I'll make some filenames up to show the trial and error process,
engine_temperature_model_left_sensor_measurement_no_lowpass.m engine_temperature_model_right_sensor_measurement_10min_lowpass.m engine_temperature_model_include_humidity_terms.m engine_temperature_model_internal_and_ambient_sensors.m
And regrettably they may be in a directory with a long title since that is how I keep track of different data collection projects, .../Projects/EngineTemperature/Measurements/Interior Track/
Walter Roberson
on 6 Aug 2018
Subdirectories.
Adam
on 7 Aug 2018
I can't actually find the section on packages in the Matlab help apart from this one which focuses on classes, but it is even simpler for functions.
Simply create a folder with a '+' at the front of its name and that becomes a package e.g.
+engine_temperature_model
Then inside that folder you create files called:
left_sensor_measurement_no_lowpass.m
right_sensor_measurement_10min_lowpass.m
etc
And when you refer to them in code or call them on the command line you refer to them as e.g.
engine_temperature_model.left_sensor_measurement_no_lowpass.m
i.e. the package name followed by '.' followed by the name, so the final thing is very similar to your long name, but you syphon off that common prefix into a package name.
I ebb and flow on whether or not I like packages. Since I write mostly classes I recently ended up using packages for inheritance which leads to the bizarre situation of me having loads of files with exactly the same name because the descriptive part that differs (the specialisation) is in the package name now rather than the filename, so when I open them in the editor they just all show up with the same name! They can still be useful for collecting together code though, and if you have a long scope where you refer to many functions from the same package you can just put e.g.
import engine_temperature_model
at the top and then you can just refer to each by its filename without needing to constantly prefix the package name.
KAE
on 13 Aug 2018
This is good to know about, thanks!
Categories
Find more on Naming Conventions in Help Center and File Exchange
Community Treasure Hunt
Find the treasures in MATLAB Central and discover how the community can help you!
Start Hunting!
