Showing results for 
Search instead for 
Did you mean: 
Showing results for 
Search instead for 
Did you mean: 

Community Tip - When posting, your subject should be specific and summarize your question. Here are some additional tips on asking a great question. X

File name length limit STILL 31 characters!!!


File name length limit STILL 31 characters!!!

Please PTC, please remove this ridiculous limit... it's 2017 for God's sake....

23-Emerald II

Long requested... Remove the limit of 31 characters in creo file name If you have maintenance, you can vote on the product enhancement request.

This has been in the planning for a long time with no implementation in sight.

23-Emerald II

Duplicate request/complaint!

How many PTC programmers does it take to fix the length of the name field?

32, but only 31 work.

I appreciate the replies... I know this is a duplicate complaint.  I just needed to rant about it since, at the moment, it's interfering with my job, once again.



With 26 alphabetic characters, 10 digits, and the underscore you have only 37^31 possible names or 4113897303606771042156868599311296618503721408813.

Did you run out?

It's an easy limit to hit when making filenames into encyclopedia entries covering revision history and routing and material and who worked on it and what the release level is and so many other non-name factors.

The good news is they are apparently going to increase the limit, but I shudder to think of looking into a model tree with part names of 512 characters, or maybe 1024 just to be sure.


Hi dschenken,

Yes, I ran out.....I got to part number 4113897303606771042156868599311296618503721408814 and had an error.

I know you're trying your best to belittle me or others who might have issue with the limit, but there just might be other issues that you haven't considered.

No, I (we) don't use such long filenames for parts or assemblies we create for our database at my job.  I think such long filenames are silly, too.

However, as you may or may not know, dealing with customer CAD many times requires much longer filenames.  Having to truncate them to be friendly with our database is often time consuming, and shouldn't be necessary at all... hence my original rant/complaint.

Here is an example part number from an automotive manufacturer I deal with (yes, underscores, and all):


Imagine hundreds of these part numbers for a larger assembly.... maybe now, you understand.

A 31 character filename limit is ridiculous.  Yes, this is a repeat complaint, but it's still not fixed in the latest version of Creo...unacceptable.



It's hardly belittling to point out the lack of need for a feature, though perhaps your customer should feel ashamed of encoding a good portion of their process management into plain text. 22032010 looks like a day-month-year, for example. could be reduced to 3 ascii characters instead of 8. Dashes could be used to terminate fields so that empty "_"'s were not required to align fields.


I can't fix Windchill, Creo, or your customer, so don't belittle me for expressing my own clearly marked not-all-about-you rant


I can suggest that in order to handle your customer, you use a hash function on the original name. This will reduce the lengthy name to any number of characters, and 31 will be plenty. To decrease the odds of collision, add a random number to the customer number that is generated with the date field as the seed value so it will be repeatable. The original name can be stored as a parameter that is declared to Windchill, if you like, so that Search can find ir. By using a hash with a seed, it isn't absolutely required to keep a table of all the conversions; any component file that is opened can be inspected for the original number and any request by customer number can have the hash generated to find the component hash number.

23-Emerald II

A lot of times those super long, underscore separated fikle names are gneerated by the software doing the export becasue it has been programmed to add the date at the end, company name at the beginning, etc.

There is NO reason that when you import a file like that that it cannot be renamed before you do the import into a reasonable length file name. Users have imported STEP files and end up with P10xxx.prt component names becasue the software doesn't have a name for that component on import. Then you start getting into name conflicts as another user imports another file and Creo doesn't know that P010008,prt is already taken. Then Windchill complains that te part already exists and If lucky the second user does not foorce an override causing the first assembly to now have a wrong component.


@BenLoosli and the others who mentioned random and meaningless filenames, I have a rant for you 🙂


Purely random and forced sequential filenames are stupid.  Modern Databases should be able to auto create filenames and propagate attributes based off basic programming (even excel can do this!).  E.g. if I want certain parts to be in certain part ranges, why is that so hard for modern software?  The inability to do this seems terribly outdated and bad/lazy programming.  With very low effort I could get excel to do this, and I am can barely do VBA.  If I want a filename to start with a year code, project number, model number, etc, I should be able to do that.  If I can even program the naming logic in excel, then a real database should be able to do this easily without the every growing scary "C" word (Customization...ahhhhh! Robot surprised ).


To be able to look at a P/N and immediately understand useful information about it is powerful, and should be easy to auto number based off of basic criteria.  If your database cannot do this without doing that scary "C", stuff then your database is garbage.


End Rant. 🙂

"When you reward an activity, you get more of it!"
23-Emerald II

Autonumbering can be done with an OIR, but that requires you to use Windchill to create the part numbers, not Creo.

The OIR can bring in various components of your naming convention and the append a sequential number of uniqueness.

However, it is limited in how much data can be pre-assigned in the code.


If you have multiple prefixes to your parts, then something else needs to be done.


It is NOT the database that is creating the numbers automatically, it is the UI programming. 

Excel can build part numbers to your specs, but someone has to program the logic into the Customized code.


23-Emerald II

Long file names are why databases where invented with search tools.

Keep the actual file name short and meaningless. Make the Common Name something intelligent and use the search feature to find the cross reference.

At one company we were discussing how long to make the filename field in the database and the longest name we came up with was like 26 characters. That was for a secondary NC program filename where we used the revision and NC machine code with operation number in the name. For our standard engineering part numbers, we only needed 18 characters and those were also a special use naming. The corporate 'standard' file name was 7 characters in length. We had spent 6 hours with people from 8 divisions discussing how long to make them. We finally settled on 64 characters, just to please everyone and allow transitions when companies were acquired.



It seems logical to keep filenames short and meaningless.

And I assume this is also how PTC intends it, as they provide means for an auto generated number for the file name, and also expect the file name to be unique:


file name.PNG


What I do not understand however, is that they then use the (meaningless) file name as the primary identifier in all other dialog boxes and info pages, e.g.:


File - open dialog:


How is one supposed to know that 0381212444.asm is the actual assembly to be opened? It's a meaningless name.


In this case, one can argue that the correct procedure is to search in Windchill instead, and select "Open in Creo".

But the same goes e.g. for the "assemble" dialog box, which is identical to the "File - open" dialog. I don't know an alternative for this straight from Windchill...


Also e.g. in Windchill:


The Common Name is shown under "CAD Document Attributes", but all the other fields refer to the file names, e.g. also in the  structure view. I know these views can be customized, but it really wonders me why on the one hand it seems to be intended that file names are meaningless, auto generated numbers, and on the other hand in the standard Windchill layouts, the file names are used as the main identifiers...


Also the model tree shows these "meaningless" file names. I know the Common Name can be added as an extra column, but this takes up valuable screen space, and is IMHO less readable (e.g. not in the leftmost column, not indented, etc):



In a company I worked for previously, this was 'solved' by giving a readable file name to each 3D component, instead of a "meaningless" number.

They had a customized 'file - new' dialog, which checked for file name uniqueness, and added some random characters to the end of the file name to ensure this uniqueness (hereby limiting the nr of characters to even less than 31...).

I think this is the way we will also go, albeit without the customisation. Only real drawback I see is that, without this customisation, you only know if the chosen filename effectively is unique upon check in. Which probably also will be annoying but I don't see a better solution currently...



Johan Rutgeerts 



23-Emerald IV

It's been over 16 years since PTC purchased Windchill and it's still not properly integrated with Creo.  There are many, many product ideas on this community highlighting these differences with the goal of getting them fixed but unfortunately there hasn't been much progress.  These fields and their usage are core to both Creo and Windchill and changing them so they actually agree and make sense is going to take a bunch of work for either the Creo developers or the Windchill developers.  Unfortunately the current approach seems to be to leave them both alone and just live with the poor integration.  Keep in mind as well that making these agree with each other isn't going to sell any new software, so this greatly reduces the motivation for PTC to actually do something about it.

Your comment about taking extra screen space is a problem I pointed out about making the names longer. Since most names are MSC to LSC (most significant character to least significant character) it's very easy to end up having to increase the width of the display to see all the characters. If the file name field is wide enough I foresee:




I'd say 512 characters might do it, because none of these will be abbreviated.


And then there will be demand that each feature in each model have that as a pre-fix so that at the top assy they can be more easily identified, is what a system admin concerned with appearance over function might say, because they don't like seeing "CSYS0" on the screen and not immediately knowing which component it belongs to.

I wholeheartedly concur...

This functional change could hardly be called an enhancement or improvement... it's an essential necessity. This "CREO IDEA" is over 5 years old.  While some creo uses don't find the file name length a hindrance, many of us have a need to identify parts, assemblies, and drawings with sensible and practical names.  While this is a testament to the variety of uses of creo, the length of file names should not be a limitation to those of us who would benefit by this capability.  15 years ago, 31 characters was enough to discern between parts and assemblies developed for a few clients.  Now, with thousands of clients, and hundreds of thousands of distinct parts that would more easily be understood with meaningful file names, this has become a limitation of productivity and profitability, especially while trying to compete with other growing contemporary CAD providers.

It is obvious, from the Replies, that CREO is used in a vast variety of implementations.  Not everybody needs the capability to use long, or even descriptive filenames for CREO files... but a great many do.  And just because a computer file name could be 255 characters long (there are other limitations - because of file path), doesn't mean that the use of the longest file name possible is practical, or sensible.  Anybody who wants to could still use the default short incremental file names... just please give me the contemporary tool of sufficiently long file names (maybe 50 or 55 characters would suffice for the next 10 years or so - and still leave 200 characters for the path), so that I can be descriptive when I have the need.  There are occasions when sufficiently descriptive file names simply makes it easier to be productive, and competitive.  If it wasn't for descriptive names, would still have to be identified by (yes - there are already website names that exceed 31 characters and are reasonably descriptive - look it up).  And I still name files in my documents directory something meaningful to me, even though I don't have 10,000 files in there.

I dug this one up while confirming the file name length and writing a batch script to rename some 600 files imported from SolidWorx.  Yay, fun times.

At minimum for Legacy purposes, and for things like emails stored in WC, the length should not be limited (WC should just match Windows and other supported OSs), because when you are importing something it increases the likeliness of a poorly thought out migration where users are forced to truncate the file names and essentially lose information that was stored in the file name for many years prior to migrating to WC.


@bsingleton and all others reading, do yourselves and your customers a favor and do the following:

  • Migrate the long filename as another field (name, description, or better yet create a non-required field/attribute such as Legacy_filename)
  • Get your company to decide on a standard naming scheme for the filename/number meaningful and not random (smart sequential is better), and then use that going forward. 
  • Get your company to use your company created attributes, or create some, to capture essential information that you would want to search by later (e.g. product name, category, etc).
  • Update your standard.

This way you might actually be able to narrow your search when trying to find the right document later.  This is advise that I wish we received and followed during a past migration because it would have put us in a much better place now...rather than doing a search and getting a hundred files that no longer have a descriptive name and you have to open them all to find the right one...every time you do a search!


Little pain upfront, but a lot less pain and much more benefit later on (read: increased productivity & reduced user frustration).


Hopefully for you this will not be great advise too late (like Mom yelling "careful" after she hears you get hurt...or the kaboom! Smiley Happy )

"When you reward an activity, you get more of it!"

2023 and still counting.


Finally we have at least a target for the fix of this problem, Creo 12!

So possibly around 15 years from product idea to implementation for a thing that has not been a problem in any other program for decades, that's nice.


Top Tags