You asked Windows to create a file, and gave it a name. Windows said, "OK, no problem!", and you got a successful return from open, but behind the scenes, Windows munged the filename. That's why you don't get an error, and Perl probably can't be reasonably expected to catch this sort of thing, as it runs on over a hundred different platforms, and does not guarantee filename in = filename out.

The colon is of course the volume separator on Win32, so while it's not a valid Win32 filename character, it is a valid path character supplied to open, (just as you might open C:\Windows\Crash). It of course isn't doing what you expect, and then I don't see how a "volume" of testlog_8- makes any sense. Chopping off the : and anything that follows, and saving a file with what would be the volume name makes even less sense, but it is what it is, I guess. DOS is, well, a bit different. :-)

Win32 naming is, well, a bit convoluted. This MSDN naming guide article illustrates the rules.

I'm not sure why you'd end up with random characters in your output logfile when you are generating the filename, but the solution is probably one of either a) making sure your filename generator function doesn't use those characters, or b) filtering out invalid characters before the call to open (or erroring out on invalid characters, perhaps).

If you need cross-platform support, it's a little trickier, but you also just be extra-picky and allow alnum, underscore, and dash, for example. I'm not aware of a module that portably processes filenames, otherwise that's what I'd recommend. In practice, a simple regex usually does the trick: $filename =~ s/[^\w-]//g;, but see File::Spec for some help with volume and path components, if need be. Mind the encoding.