<i>The root cause of all this is a relatively obscure NTFS feature called alternate data streams.</i><p>Obscure indeed, I've never seen them used for anything other than hiding malicious content. Curious, I read about them on Wikipedia[1] and it turns out they were originally created to support resource forks in Services for Macintosh. Browsers also use them to flag files downloaded from the internet.<p>[1] <a href="https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.28ADS.29" rel="nofollow">https://en.wikipedia.org/wiki/NTFS#Alternate_data_streams_.2...</a>
The colon has been special since the dawn of DOS. For instance, you cannot use "con:" as a file name. (In fact, in a fit of extreme stupidity, DOS also claimed some devices with no Colon suffix, like "con" and "prn", effectively making these into globally reserved names in any directory.)<p>Stock Cygwin does something special with the colon character, so the Cygwin git shouldn't have this problem. A path like "C:foo.txt" is not understood by stock Cygwin as a relative reference in the current directory of drive C; the colon is mapped to some other character and then this is just a regular one-component pathname.<p>In the Cygnal project (Cygwin Native Appplication Library), paths passed to library are considered native. So that certain useful virtual filesystem areas remain available, I remapped Cygwin's "/dev" and "/proc" to "dev:/" and "proc:/", taking advantage of the special status of the colon to take this liberty. You can list these directories (opendir, readdir, ...) and of course open the entries inside them; but chdir is not allowed into these locations. (Unlike under stock Cygwin, where you can chdir to /dev). chdir is not allowed because then that would render the library's current working directory out of sync with the Win32 process current working directory, which would not be "native" behavior.
It's not alone. In MS SQL Server, you can name a database "foo:bar". If you give a database such a name when you restore it from disk, you'll find that the database takes zero bytes on disk (at least, that's what Explorer claims) Your disk space is gone, though.
Related to this bug: used to be a vulnerability in IIS back in the late 90s where you could append ::$DATA to a file name (e.g Foo.asp::$DATA) and download a server-side script's source code.
I had a related problem with Dropbox. Some files uploaded from my Linux machine were not synced to my Windows machine. Later I narrowed down this problem to images being saved from Twitter, which have URLs ending with ":orig". On Linux, Firefox happily saves such images as "blahblah:orig.jpg", whereas on Windows it uses space instead of a colon. And of course Dropbox on Windows would completely ignore filenames that contain colons and tell that the directories are synced, when they obviously aren't.
This is interesting. I was just recently working on an app where I wanted to ensure the UI wouldn't accept problematic characters in filenames. Obviously, Unix has problems with '/'. I'll add ':' to the list. That's unfortunate. What else should portable apps avoid?
MacOs (i.e., Os9 and before) had special meaning for colons, too. I wonder what would happen for git on those platforms.<p>Edit: Apparently colon is _still_ a special character on Mac! <a href="http://stackoverflow.com/questions/13298434/colon-appears-as-forward-slash-when-creating-file-name" rel="nofollow">http://stackoverflow.com/questions/13298434/colon-appears-as...</a>
The flip-side of this:<p>I was running a fuzz test on a backup tool, which verified that file data and metadata (including timestamps) as reflected by Windows were exactly as produced by the fuzz test.<p>I noticed that for some ".eml" files this was not the case. The mtime of these files was being modified by something else after the initial create by the application. At last, it came down to a Windows process which was automatically indexing ".eml" files and creating an ADS for each of them, thereby touching the mtime.<p>This was intentional on the part of Windows, but I never saw it coming.
The problem should be addressed, but the proposed workaround seems strange. So git should refuse to write the file to disk? How am I supposed to use a git repo that contains such problematic files on Windows then?