If by "expected" you mean the default Windows way, yes that's true. But I would expect the ability to sort things alphabetically, the way that earlier Windows used to do it: the sorting would consider each character on its own, left to right, in the filename, without regard to any characters coming after it. "0" (zero) should always file before "1". Because "00067H" starts with "000", it should NOT file AFTER "0007N8". (Actually, because I only gave examples of 3 file names out of the 134 in the project, this example does not illustrate how severe the problem is. 00067H actually files between 0066C8 and 0067M2. So, instead of 00067H--which is the sixth clip--appearing in the 6th position as normally expected, it appears way, way down the list after the 66th clip. For those unfamiliar with P2 filenaming conventions, the 1st four digits are the actual sequential clip number, and the last two characters are randomly assigned alphanumeric characters that have no relationship to the clip sequencing.)

Yeah, sorry, that particular issue bothers me too with P2 clips. But we decided that matching the Windows Explorer sort order was the least bad solution. The P2 file naming is the main place this happens because of the uniquifying random characters after the clip number in the file name. That means that any better sorting would require P2-specific code in the explorer window, which we generally try to avoid because our P2 support is all in a plugin. So, I regretfully say that it's highly unlikely we'll change the software to sort in the human way you'd naturally prefer for these files. I hope you understand.
Chris

applaud your decision Chris - There are in fact so many good file rename utilities out there in the Windows OS which can rename the P2 files into any sort order you would like. And then become reasonable.

I don't know of any P2 editor who would not want to do this before editing files into a project. Just make the sort order on Win plafform so much better.

It's not surprising that 00067 comes after 0007 but it would be a pain if you were relying on filenames for sort order rather than relying on timecode.

I don't know if renaming P2 files is a reasonable option, maybe there are related sidecar files that you'd want to preserve. If renaming files *is* an option then just inserting a dash after the fourth character would solve the issue.

I rename all my files this way. Currently we're capturing straight off the camera cable to FCP. This method doesn't capture TC off the camera. Our logger/script supervisor kindly set up the capture to automatically put a number at the end of the filename, I then grab the files, copy them out of the FCP environment, and use a renamer to move the numbers to the front of the name. Everything sorts in order this way.

The way the Vegas P2 plugin works is that it starts with the video clip and looks for the related clips as follows. Say the video clip is 0001XX.MXF. The audio should be in files ..\..\CONTENTS\AUDIO\0001XX01.MXF thru ..\..\CONTENTS\AUDIO\0001XX04.MXF. If not found in the ..\..\CONTENTS\AUDIO folder, then we look for the audio files in the same folder as the video. The clip metadata likewise should be in ..\..\CONTENTS\CLIP\00001XX.XML, or in the same folder as the video. We do not use any of the other files (VOICE, ICON, PROXY).

(that's a bit of a simplification, but it's close enough)

So if you choose to rename, make sure you rename the video, audio and clip in the exact same manner, preserving the audio channel number in those filenames, and optionally keep or ignore the P2 directory structure.

Thanks for the reply, Chris. At least I understand the situation, even if I can't say I'm really happy with the outcome. :( I'll just lay all the blame on Microsoft, who threw me for a loop several years ago when they made that weird change. Yes, sometimes a string of digits in a filename is intended to be an integer; but sometimes it isn't, darn it... It was especially maddening when I had already been creating filenames for years based on character-by-character sorting, so that numerical strings would only file as integers when they were meant as such (and not, for example, when they were dates--I never wanted a file called "200709.txt" to file BEFORE a file called "20010101.txt"). It never occurred to me that MS would do its best to outwit me on that one; but of course, over the years it's become clear that I should have expected such things... (okay, MS rant over.)