yardag nechemya zakariah

[Azalee Freas]

In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string" where "" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.)

The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength parameter of the GetVolumeInformation function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".

The "\\?\" prefix can also be used with paths constructed according to the universal naming convention (UNC). To specify such a path using UNC, use the "\\?\UNC\" prefix. For example, "\\?\UNC\server\share", where "server" is the name of the computer and "share" is the name of the shared folder. These prefixes are not used as part of the path itself. They indicate that the path should be passed to the system with minimal modification, which means that you cannot use forward slashes to represent path separators, or a period to represent the current directory, or double dots to represent the parent directory. Because you cannot use the "\\?\" prefix with a relative path, relative paths are always limited to a total of MAX_PATH characters.

There is no need to perform any Unicode normalization on path and file name strings for use by the Windows file I/O API functions because the file system treats path and file names as an opaque sequence of WCHARs. Any normalization that your application requires should be performed with this in mind, external of any calls to related Windows file I/O API functions.

Understand that enabling this registry setting will only affect applications that have been modified to take advantage of the new feature. Developers must declare their apps to be long path aware, as outlined in the application manifest settings below. This isn't a change that will affect all applications.

The registry value HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD) must exist and be set to 1. The registry value will be cached by the system (per process) after the first call to an affected Win32 file or directory function (see below for the list of functions). The registry value will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value, a reboot might be required because some processes may have started before the key was set.

These are the directory management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CreateDirectoryW, CreateDirectoryExW GetCurrentDirectoryW RemoveDirectoryW SetCurrentDirectoryW.

These are the file management functions that no longer have MAX_PATH restrictions if you opt-in to long path behavior: CopyFileW, CopyFile2, CopyFileExW, CreateFileW, CreateFile2, CreateHardLinkW, CreateSymbolicLinkW, DeleteFileW, FindFirstFileW, FindFirstFileExW, FindNextFileW, GetFileAttributesW, GetFileAttributesExW, SetFileAttributesW, GetFullPathNameW, GetLongPathNameW, MoveFileW, MoveFileExW, MoveFileWithProgressW, ReplaceFileW, SearchPathW, FindFirstFileNameW, FindNextFileNameW, FindFirstStreamW, FindNextStreamW, GetCompressedFileSizeW, GetFinalPathNameByHandleW.

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.

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.

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 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.

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.

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! ).

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.

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.

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):

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...

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:

c01484d022