Oh yes. I have here another moral. And it’s not good for me, because it’s (again) described in documentation (but who reads it when there’s nice IntelliSense?). In my program ID3 renamer I have couple of custom IO operations. One of fundamental methods is for enumerating directory(ies) for all MP3 files. It’s based on Directory.GetFiles and few functions inside ID3 renamer need exact order of files. One of these functions is FreeDB search. When I was renaming files on my network share, it wasn’t finding anything. But when moving the directory to local drive everything was fine.
After some debugging I found, that the ordering of files from network share is different than from local drive. If you look to documentation you see:
The order of the returned file names is not guaranteed; use the Sort() method if a specific sort order is required.
Ahh, there’s your problem. 
Sadly enough, the ordering from local drive looks stable and it’s based on filename as expected. Thus in a lot of cases you’ll not smell that something may go wrong. But on non local drives (for me my NAS) you’ll hit this immediately.
Never mind, could be worse (my first shot was some bug in my “MP3File” class and that will be really bad, as it could break users’ files). This can be fixed easily.
The ordering from local drive may look stable, but functions in other programming languages usually returns file as they are found on drive. When you use some defragmentation tool, it usually sort files by name, maybe that is reason why it looks as it works on local hard drive ?
When you copy files from one directory to another, you usually copy it by some file manager and it shows file sorted. So files are created with same order and file list looks sorted too.
Hmm, that may be possible. Anyway, I’ll use sort to be on the safe side.