Windows Weirdness
Although I'm not a Redmond fan (shock horror), I do feel that NTFS is a pretty decent filesystem.
I've read up on it's guts some time ago, and it supports lots of fine features like symlinks and the like. ACLs are also supported natively, and additionally it's internal structures are reasonably straightforward. In fact, the major issue I have with it, is that it takes up about 10% of your disk just for it's structures and metadata. Yes, that's 10% of your disk gone, just because you formatted it as NTFS.
I just found another reason to not use windows, however: the artificial restrictions that it places on what is at heart a very nice filesystem. I was messing about in a script that does FTP transfers from a Solaris box to a Windows box, and decided to replace the 'ls $localdir' with a find command, to avoid error messages on directories.
This in se good idea, had an unxepected downside, however: Solaris 9 find helpfully also reports hidden files without being told so. Thus, the script uploaded a number of temporary files, named .filename_date_uuid.. Yes, *with* a dot on the end of the filename. Now, most modern filesystems don't really have a problem with that. In fact, NTFS doesn't, either. It happily accepted the filename.
Those filenames turned out to be a problem with the application that then processes the files, however. In fact, that's how we noticed the files got transferred: the application just can't swallow them and waits for you do remove them. So I went to fix the script, while the windows guy removed the files. Except that he couldn't remove the files: Windows told him it couldn't read from that disk. Everything else was fine, though, and this being a server, we *knew* the disks weren't broken, or it'd have shown up somewhere.
I tried logging in through the FTP daemon, but found that I couldn't delete them there, either. The system cannot find the file specified.
Turns out that the Windows API still imposes a number of artificial restrictions on filenames and such, which are entirely not there in the underlying NTFS. I can only surmise that someone thought this was a brilliant idea because a) some programs wouldn't be able to handle it, and b) users would get confused if they can copy only half of their files from their harddisk to a floppy or whatnot (NTFS to FAT).
So, the Windows API let an illegal filename through on the way in, but won't touch it afterwards. Brilliant programming, mates.
The Google is my friend, though. Turns out that if you prepend \\?\ (backslash-backslash-questionmark-backslash) to the filename (full path may be required, not sure), you tell the Windows API to ignore the artificial restrictions, or at least do-what-I-want-you-idiot. Thus, deleting \\?\c:\path\.stupidfilename. worked a charm.
That syntax is surprisingly similar to that of a remote share, actually. Could the questionmark be an alias for "localhost without api restrictions" ? Or maybe it's a pre- or suffix to hostnames that tells it to turn of safeties on the share ?
Anyway, this is a crappy issue, that should've been solved at the api level ten years ago. NTFS is a perfectly fine filesystem that's entirely wasted on the likes of Redmond, and this is another reason why I utterly refuse to have anything more to do with Windows than what I have to to get my job done.
/rant