QuickTime for Windows returns bdNamErr (-37) error with long Windows file names

Q:  I'm getting the bdNamErr (-37) error when calling NativePathNameToFSSpec on my Windows PC with QuickTime 7. The paths I'm using are perfectly valid Windows paths to files on my hard drive. What am I doing wrong? Also, can I use the data reference APIs such as QTNewDataReferenceFromFullPathCFString, QTNewDataReferenceFromCFURL and so on to avoid these types of errors?

A: There's a limitation in QuickTime prior to version 7.4 which restricts any file name plus extension to 63 characters or less. The full path may still be MAX_PATH (see WINDEF.H) characters long, but the file name must be 63 characters or less.

Also, the text encoding of the pathname passed to NativePathNameToFSSpec must match the system code page of the Windows system. This means you cannot use Unicode pathnames (either UTF-8 or UTF-16) with this function.

Starting with QuickTime 7.4, the limitation on the length of a file leaf name is now 255 characters, rather than 63 characters as it was in earlier releases. The full path must still be less than or equal to MAX_PATH characters.

In addition, the data reference APIs (QTNewDataReferenceFromFullPathCFString, QTNewDataReferenceFromCFURL and so on) in QuickTime 7.4 now provide more robust support for Unicode pathnames, though these pathnames must also be less than or equal to MAX_PATH characters.

The FSSpec data structure does not allow Unicode characters. Therefore, it is not possible to represent a file whose pathname contains Unicode characters. With QuickTime 7.4, the Carbon Resource File APIs are not compatible with Unicode pathnames.

You can obtain the long form by calling the GetLongPathName Windows API.

Document Revision History