Critical Git Security Vulnerability Announced 148
An anonymous reader writes Github has announced a security vulnerability and has encouraged users to update their Git clients as soon as possible. The blog post reads in part: "A critical Git security vulnerability has been announced today, affecting all versions of the official Git client and all related software that interacts with Git repositories, including GitHub for Windows and GitHub for Mac. Because this is a client-side only vulnerability, github.com and GitHub Enterprise are not directly affected. The vulnerability concerns Git and Git-compatible clients that access Git repositories in a case-insensitive or case-normalizing filesystem. An attacker can craft a malicious Git tree that will cause Git to overwrite its own .git/config file when cloning or checking out a repository, leading to arbitrary command execution in the client machine. Git clients running on OS X (HFS+) or any version of Microsoft Windows (NTFS, FAT) are exploitable through this vulnerability. Linux clients are not affected if they run in a case-sensitive filesystem....Updated versions of GitHub for Windows and GitHub for Mac are available for immediate download, and both contain the security fix on the Desktop application itself and on the bundled version of the Git command-line client."
Re: (Score:2)
It's another bit of pandering to the stupid. Rather than encourage people to go into the direction of sanity, the path of least resistance is to turn the bug into a feature. Microsoft and Apple are both guilty of that. Encouraging whitespace in file names is another indicator of this.
I don't let Unix and descendants get off so lightly, either. While they have sanity w/r/t filename case and the use of slash as a path-element-separator character, they do allow allow not just blanks but also control charac
Re: (Score:2)
Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.
Re:Case insensitive file systems were a bug (Score:5, Informative)
Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.
This article [dwheeler.com] makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.
Re: (Score:2)
I don't find the case convincing at all.
Good article on file name design; thanks! ShellJS? (Score:2)
Enjoyed skimming through it, especially the point about character encoding and the value of utf-8. Many arguments for name restrictions are because it would make shell commands and scripts easier to write correctly. That suggests to me the bigger issue is the shell.
As the computer language Forth shows, there does not have to be an obvious line between a programming language and a command line. It's unfortunate our systems generally have multiple languages with different conventions. What might be better is
Re: (Score:1)
Obviously every character except for the path separator and the string terminator should be valid. Why should the file system restrict what character encoding I want to use for my names other than restrictions that simply make implementation easier.
This article [dwheeler.com] makes a pretty convincing case that we'd be better off with some restrictions on filenames. It's hard to argue the point that allowing certain characters in filenames causes more problems than it solves.
Sorry - if the tools that we have for managing the labels that humans wish to place on their objects are lacking, we should fix the tools, not the labels. For example, I've named my dog "Crankshaft" - does that confuse mechanics? The only thing we humans have is the ability to manipulate symbols. I'd prefer to have no restrictions on the labels that I use, since they simply refer to objects.
Re: (Score:2)
Sorry - if the tools that we have for managing the labels that humans wish to place on their objects are lacking, we should fix the tools, not the labels. For example, I've named my dog "Crankshaft" - does that confuse mechanics? The only thing we humans have is the ability to manipulate symbols. I'd prefer to have no restrictions on the labels that I use, since they simply refer to objects.
It's a common problem in the programming field to make a virtue out of overgeneralization, even when it conflicts with other virtues, such as ease of use or security. What actual benefit do you get from allowing the inclusion of control characters in filenames? How does that benefit compare with the amount of pain and extra effort involved in dealing with those filenames?
The other thing is that "fixing the tools" is a complete non-starter. You're talking about "fixing" a large subset -- possibly even a m
Re:Case insensitive file systems were a bug (Score:5, Insightful)
A quick glance at that article seems more like a compelling case for teaching people how to write shell scripts properly.
If you read the article, you'll find that writing shell scripts to handle filenames containing every possible character "properly" is so difficult that virtually everyone gets it wrong. When something's been around for close to 40 years and still nobody can get it right, maybe it's time to admit that it's the tool that's broken.
Re: (Score:2)
Because some characters have special significance to the shell. That includes * and ?. In the bad old days of dos, you could enter an arbitrary character code by holding Alt while entering the 3 digits on the keypad. Character 255 looked exactly like a space but was not equivalent. Imagine the confusion one could cause that way.
Re: (Score:1)
That was my favorite way of hiding things.
Re: (Score:2)
so what?
The file system is independent of the shell. My shell probably uses different special characters than yours too - ^ means something in mine for example.
Adding complexity into the file system because people are idiots is silly. If you really need to you can wrap an idiot layer on top the file system after all.
Re: (Score:2)
All the complexity you need to add is:
if (ch <= '\x1f') {
goto FAIL;
}
How hard is that?
Re: (Score:2)
How does that stop you using * and ? in a file name. How does that stop you using "Character 255" in a filename?
It does of course stop you using utf8 filenames.
Re: (Score:2)
So you need to have some way to enter those characters when specifying a file name. Escap chars can handle some of that, but it really is best to not take chances where it can cause problems. For example, imagine a file named 'bobby; rm -rf /'
Re: (Score:2)
/ is one of the two characters I said were fine to not allow, due to implementation simplicity. So there's no need to imagine such a file name.
But I have no problem with ";" in file names (or "|", or "&", etc). I don't interpret file names as shell commands since I put the commands in the text of the shell script files not in the file names.
Re: (Score:2)
It doesn't matter what YOU interpret as a file name vs command, it matters what the shell considers a filename vs a command. Nit pick the example all you like, but if ; is a valid char, tears will result. I don't see where bobby;rm -rf * would be that much better. It's begging to be exploited.
Re: (Score:2)
I dont know if its a bug, it makes navigation more simpler.
Any evidence to back up the claim?
When 10+ years ago I was moving from Linux to Windows, the case-sensitve file system was one of the major risk factors.
But even in the beginnng, I have encountered precisely zero problems with it. And I'm the type who works mostly on the terminal and should be directly impacted by the case-sensitive file names.
The thing is, these days, nobody types the filenames manually: it is either click in GUI with the mouse or filename completion on the command line. And even if
Re: (Score:2)
Don't worry, as XKCD shows, this is not an issue [xkcd.com].
Re: (Score:2)
Re:I blame Microsoft (Score:5, Insightful)
Yeah, what's next? Case-insensitive email addresses and domain names?
Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.
Re: (Score:2)
As for me, I'm happy that we've moved beyond 8+3.
Re: (Score:1)
Yes, I remember those flame wars, but to me at the time it was UNIX against the world.
But having worked for years on minis with files names consisting of 8 characters [A-Z] and 1 level 'directories', I kind of miss being forced to use short file names like DOS had. Multi-level directories are cool though.
One pet peeve of mine is people creating file names like: "this is a book of my whole life and everything i know.doc'" drives me crazy :)
Re: (Score:2)
One pet peeve of mine is people creating file names like: "this is a book of my whole life and everything i know.doc'" drives me crazy :)
You can definitely blame Microsoft for that one (default Word filename is first line of document).
polish != Polish (Score:2, Interesting)
Yeah, what's next? Case-insensitive email addresses and domain names?
Remember, the whole reason files have names and not sequences of random hex is for human legibility. For most applications, case sensitivity does not increase legibility.
You are conflating two things that are (or should be) separate: the file system and the UI.
The file system (paths and names) should be case sensitive. If I give the VFS a string of bits that represents a file's name (regardless of ASCII, Unicode, or EBCDIC) it should take those bits and store them as-is and give them back as-is with interpreting them.
The UI (whether the GUI or maybe the CLI shell) could then make things easier for humans by treating "p" like "P", but the file system should treat them differ
Initial capital (Score:2)
There is a difference after all between "Polish metal" (geographic connotations) and "polish metal" (to make shiny).
Not at the beginning of a sentence.
Or, as another example, the sentences "I helped my Uncle Jack off a horse" and "I helped my uncle jack off a horse".
Or better yet, "I went to my Uncle Jack's stud farm and helped him jack off a horse". Not that there's anything wrong with that [wikipedia.org].
Re: (Score:2)
You wanna confine it to a handy though: http://en.wikipedia.org/wiki/Enumclaw_horse_sex_case [wikipedia.org]
Re:polish != Polish (Score:5, Insightful)
You know, one could argue that case sensitivity in file systems actually demonstrates the difference between the *nix vs. Windows philosophies pretty well. Disclaimer: I'm a Windows guy, so let me know if I'm making unfair characterizations.
*nix
*nix is about power, flexibility, and user control. It favors command-line interaction through discrete commands, applications, and scripts. This makes it extremely suitable for power-users and administrators who are willing to invest the time to become proficient in using these tools. Visual interfaces are often built on top of these command-line actions, which can create a slightly disjointed experience for more casual users who don't understand what's happening under the hood or can't easily fall back to command-line use when needed.
File system design: A file system should give back exactly what was put into. We should provide maximum flexibility and utility, even if it comes at the expensive of user-friendliness. The entire system should not be dumbed down to protect users who can't even figure out how to properly name their files, because there may be legitimate use cases for case sensitivity in file naming.
Windows
Windows is about user-friendliness. Visual tasks and interactions are emphasized over command-line actions. Applications are often extended through proprietary extensions or internal scripting rather than through command-line input and output. Because the system is build with visual interaction in mind first and foremost, users never have to interact with a command-line. This makes it easier for casual users to achieve faster results with less training, but can come at the cost of a more shallow understanding of their computers (e.g. if the visuals change significantly, users may become confused).
Filesystem design: We can't really think of a reasonable use case in which a user would actually want to create two different files in the same directory that only differ by case. In reality, it would probably be the result of an mistake, and this may cause confusion for users. Therefore, we'll just restrict the functionality to eliminate that potential error. We're willing to write a bit of extra code to preserve case but to discard it when disambiguating files.
Re: (Score:2)
There's a simplier answer to that: to be case-insensitive, you have to agree to a character encoding first, or write it down somewhere along with the name, and then you need additional code to deal with equivalences between characters in that encoding.
To be case sensitive, *nix-style, is straightforward: you just aren't allowed to use byte 0x00 (C string terminator) and 0x2F ("/" in ASCII encoding) when encoding file names. Everything else is just fine, regardless of encoding (and endianess, just in case
Re: (Score:1)
Re: (Score:2)
For a Turkish user, 'i' does not capitalize to 'I' but to dotted I (which anything but slashdot can display), while 'I' lowercases to undotted i. Now go make a checkout within the Turkish locale and try to read it within any other locale (typically, a different user or a different machine in the network).
Re: (Score:3)
Re: (Score:2)
Despite the fact that I think case-sensitivity is a Good Idea
Why? I've never heard a single good argument in favour. With programming, you often want case sensitivity to distinguish between a public Name and a private name, but the same need isn't there with files, and case-sensitivity is just more likely to lead to mistakes. I say POSIX should be changed to prefer case-insensitive filesystems.
Re: (Score:2)
Why stop there?
They should also add a spell checker and auto-correct to the file system driver just to make sure people haven't made any mistakes.
Re: (Score:2)
Personally, I prefer knowing that the filename I type is the filename the file gets. If I want to call something "finaldraft.txt" and "FINALdraft.txt," that should be up to me.
Re: (Score:2)
How about because English isn't completely case-insensitive. Pronounce this: POLISH. You can't know you're doing it properly. Now, pronounce Polish and polish. No problem, right? Similarly, Danish is an adjective referring to a nationality, while danish is noun denoting a pastry. "bismarck" (lower-case) cannot be a nineteenth-century German politician, a WWII battleship, or a city in North Dakota. Christians worship God while Romans worshipped gods.
Re: (Score:2)
Right, because it's a daily problem I have that I want to put files called Polish and polish in the same directory. And I can't think of any way to differentiate them other than capitals.
What a dumb argument.
By the way, what about when you can't distinguish them by capitals? What if I want a file about my new table in the same directory as my table of figures? What do I do then?
Case sensitivity is a good idea (Score:2)
Case sensitivity is a good idea. The problem is that trying to do "case insensitive" matching depends on the locale. If you send your files to someone else, whether or not they are the "same" depends on your locale if you're serious. For Turkish users, 'i' and dotted 'I' are the same if you're considering them as case-sensitive; for many other languages and users, the dots create DIFFERENT characters. And if you're trying to make this "easy" it doesn't go far enough; Latin "a" usually looks the same as
Re: (Score:2)
SureItDoes.
Of course, if not for the convention of all smalls in domain names we wouldn't get to snicker at expertsexchange.com
Re: (Score:2)
Technically, NTFS isn't case insensitive.
The APIs used take care of making it behave that way from an application perspective. NTFS is case preserving by default, and case sensitive in the data structures. Pretty much every API written to access NTFS drives would explode if confronted by a NTFS file system that had been used in a case sensitive manner, but thats another story.
Re:I blame Microsoft (Score:5, Informative)
Actually, Microsoft themselves has an API for accessing NTFS drives in a case-sensitive manner, and I'm not talking about the native NT API or even the FILE_FLAG_POSIX_SEMANTICS Win32 file API flag. All versions of NT from 3.1 (the first) to 6.2 (Win8; it was removed from 8.1) have support for a POSIX operating environment - basically a full Unix-like OS running atop the NT kernel - and for proper Unix-like-ness it is case sensitive.
Mind you, Win32 programs do tend to get confused by it all. For example, CMD's "dir" command will list both "test.txt" and "TEST.TXT" in the same directory, and even correctly note if they have different sizes or datestamps. However, the "type" command (print file contents) on *either* name (or some other-cased version of the name) will instead print the contents of one of the files - doesn't matter what you type, the OS will pick - and it will print it twice (once for each copy of the file with that name).
I've been using the Interix (name of the Unix-like operating environment that runs in the NT POSIX subsystem, as reported by the uname command) build of git for years now. I should probably stop - the repo my package manager used has died, and I haven't bothered to set up a different package manager yet so my packages are outdated - but I am, humorously enough, not vulnerable to this particular attack even with that outdated version.
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Just because .NET APIs call down to Win32 APIs, which call down to NT APIs, doesn't mean that they aren't all different APIs. Same for the POSIX APIs (which, like Win32, chain to native NT APIs). The POSIX ones always specify OBJ_CASE_INSENSITIVE, the Win32 ones do if you specify FILE_FLAG_POSIX_SEMANTICS, and I don't even know if .NET supports enforcing case-sensitivity... but they are still separate APIs. Nobody in their right mind writes user-mode software against the native NT API unless they absolutely
Re: (Score:1)
Re:I blame Microsoft (Score:5, Insightful)
Karma be damned...
One could alternately argue: do you feel it's a good thing for something.dat and Something.dat to reference two different files? Because that would never confuse users, right? Shall we next talk about forward slash versus backslash in path separators, and how one is obviously much more logical and intuitive than the other? Or maybe we should get into line endings, or perhaps how there really shouldn't be any distinction between text and binary files? UTF-8 vs UTF-16?
Newsflash: different operating systems have different conventions and different quirks. I'm going to take a wild-ass guess and predict that you believe the choices of your preferred OS are obviously the correct choices.
Re:I blame Microsoft (Score:4, Insightful)
Re: (Score:2)
No. Two different byte strings should identify two different files (unless one or both of them are invalid byte streams). Anything else is introducing complexity into the filesystem and potential bugs and security violations, of which this it an excellent example. Sorry, but Unix has it right, and Microsoft and lots of other systems are *WRONG*.
Re: (Score:2)
do you feel it's a good thing for something.dat and Something.dat to reference two different files? Because that would never confuse users, right?
Case sensitivity is locale-dependent. If the user is bilingual, the file system then has to guess which language the user is thinking in when opening files.
Re: (Score:2)
As I understand it, in English a case-sensitive filesystem would have "fish" and "FISH" be the same, but that would be an error in a Turkish one. What's lower-case of "STRASSE"? Should the filename with the "ss" be the same as the one with the letter that looks like a beta? I used to be a fan of case-insensitivity, but I've come down on the side of preferring the system that actually works everywhere.
Re: (Score:2)
For creating case-insensitive file systems.
What.
The.
Fuck.
IBM probably deserves some credit (or blame) as well, VM/CMS's filesystem may not have been case insensitive (since filenames were all upper case), but 3270 monitors had a switch that would toggle the screen display between mixed (or lower) case to all uppercase. You could still type in mixed case, but it was displayed as upper case.
Re: (Score:2)
Are there any advantages to case-sensitive file systems?
Re: (Score:2)
Yes. There is only one possible name for addressing a file. For a case-aware, but case insensitive, you get up to 2^n variants for a name n letters long. And you _can_ have the same name with different capitalization in a directory as result of errors.
Re: (Score:2)
Yes. There is only one possible name for addressing a file. For a case-aware, but case insensitive, you get up to 2^n variants for a name n letters long. And you _can_ have the same name with different capitalization in a directory as result of errors.
Funny, since Linux does everything it can to break a canonical name model with symlinks. In fact, you could mimic a case-insensitive system with 2^n symlinks like /foo/bar/COnFiG -> /foo/bar/config. And the captialization is the cause of errors in mixed environments:
1) Create file on Windows called "Foobar.txt".
2) Copy it to your Linux machine.
3) Rename it to "FooBar.txt"
4) Do lots of work on the text
5) Copy it to your Linux machine
6) Copy the Linux directory back to Windows.
There's now a 50-50 chance th
Re: (Score:2)
A symlink different from the file it points to. You are probably confusing it with a hardlink. At least get the basics right before you post something like this.
Re: (Score:2)
They work for bilingual users. Case-insensitive file systems are limited to languages with identical case folding. The rest of us are screwed.
Re: (Score:2)
MS chose case-aware (you can use case), but case-insensitive. In typical MS fashion, that is the absolute worst possible behavior that still somehow gets the job done. Case unaware, or case sensitive are both fine, but this stupidity cause countless problems.
Re: (Score:2)
So has COBOL.
Re: (Score:2, Troll)
I boot linux from a vfat formatted USB stick, you case insensitive clod.
Only bad for pulling untrusted content. (Score:4, Informative)
This is only an issue if you pull untrusted content, and are on a case insensitive file system. This is not typical git usage, but its a good thing to know about.
If you do thing like pull from a repo, and run the build scrips without reading them first, you already had worse security problems, and there is nothing worse about this. It seems like the main fear would be (case insensitive) servers doing automated pulls and such getting compromised by hostile repo.
Servers that pull from lots of git repos could spread such attacks virus style, but I really don't think many such networks of auto git pulling servers exist. More likely is a specific targeted attack against some servers, but I expect most run on case sensitive file systems.
Re: (Score:2)
Unrelated to Github (Score:5, Informative)
I'm puzzled that Github is stated as the main actor here. They are just
broadcasting the official announcement from the git mailing list. They are not
involved in the initial discovery, subsequent investigations or fixes. How come
this post end up giving them most of the credit? Have people already
forgot that Git and Github are different entities?
Re:Unrelated to Github (Score:4, Interesting)
The headline is wrong too. This isn't a Git vulnerability. This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names. That Git has a workaround for their broken behavior is good in the short run, but the correct solution would be to fix Windows and Mac OS X so that they can tell the difference between upper and lowercase letters.
Re: (Score:2)
POSIX is, if we are to be really strict, about interaction between Unix variants. So, while it can certainly argued that it's a fault with OS/X, it's not a fault with Windows, since it's not a Unix OS. And hilariously, I know of no Linux distro that is fully POSIX compliant for that matter, nor is FreeBSD or OpenBSD etc.
Re: (Score:2)
No, stop being an idiot.
"regular users" click on files in a list or 2-d grid. They would not even notice if the filesystem allowed more than one file with the same name, and the certainly do not give a damn about case insensitivity. Even if they type at a terminal they use filename-completion and do not care either.
It is also clear that it has nothing to do with user-friendliness or they would map more common errors, such as multiple spaces to single ones, removing leading and trailing whitespace, or mappin
Re: (Score:1)
All modern systems are capable of storing different strings for filenames in different cases. So no, Linux has it right and Windows has it wrong. Sorry to burst your bubble, but you are simply Wrong, with a capital W.
Re: (Score:2)
All modern systems are capable of storing different strings for filenames in different cases
Including Windows (with NTFS) - but the API used to access the filesystem normalizes everything. It leads to a lot of weird behavior...
Re: Unrelated to Github (Score:5, Informative)
Re:Unrelated to Github (Score:5, Funny)
WTF is Git? Is that a new fork of git? Cause I can't tell what you are talking about because you put the wrong case.
Re: (Score:3, Funny)
Re: (Score:3)
Tag: NOTABUG and WONTFIX. Case aware filesystems so you can have normal names and not like AUTOEXEC.BAT and CONFIG.SYS from the DOS days is great, case sensitive file systems are a really bad idea. Is there any kind of sane situation where you'd like to have two files "Config" and "config" actually coexist that isn't just begging to be confused/abused/exploited? For a marginal performance optimization all POSIX systems have shitty usability. Why am I not surprised? I guess for a server it just doesn't matte
Re: (Score:2)
This is a flaw in Windows and Mac OS X where they fail to differentiate between two similar but different file names.
Odd, I thought it was exactly the opposite. Linux doesn't interpret the names at all. Only '\0' and '/' (in C/C++ notation) are treated specially by Linux in what can be allowed as file name. The rest is just an array of bytes. Is Mac OS X or Windows the ones that try (and I said try, since I'm not sure they achieve it) to protect the user from security and confusion problems. Is not just case sensitivity, think of pre-composed characters, for example (distinguishing modified+character from character alread
Re: (Score:3)
No it isn't.
Both NTFS and HFS+ are file systems that are case insensitive and case preserving (by default). They work as designed. They have always worked that way as the people who ported git to those platforms should have known.
Just because you don't like the way NTFSD and HFS+ work and it makes the programmer's job a little harder doesn't mean there is a bug.
Re: (Score:1)
Re: (Score:1, Informative)
Have people already
forgot that Git and Github are different entities?
Yes. GitHub is where all the git repositories are. Not only that, Github is where all the coders are. If you don't have a GitHub profile, you don't even exist.
SVN? (Score:2)
This isn't a specific git problem. It's a windows problem.
I have source trees that I can't check out of an SVN server on windows because either the files get overwritten by different case filenames being aliased onto the same file or the file tree being to deep for windows.
Re: (Score:3)
I have source trees that I can't check out of an SVN server on windows because either the files get overwritten by different case filenames being aliased onto the same file
Windows' behaviour makes sense. What doesn't make sense is having Readme and readme in the same directory. What possible reason could one have for differentiating 2 files on nothing but case?
Re: (Score:2)
What possible reason could one have for differentiating 2 files on nothing but case?
1) Programmer copies files from linux box to windows box of a certain age.
2) Programmer makes some changes in windows land.
3) Windows loses the case of the filenames
4) Programmer copies files back to the same directory in linux land. Now there are two different files README and Readme.
Re: (Score:2)
windows doesnt "lose" the case of the filename, dumbass - someone would have had to change it. Unless maybe its win3.1, in which case its the fucking devs fault for being a cheap shit.
That's why I said "windows of a certain age" dumbass.
OS X - Case sensitive and sensationalism (Score:1, Redundant)
No developer worth mentioning runs OS X with a case insensitive file system, and there are only 2 sets of Applications that don't work on case sensitive file systems on OS X: ... well I have no fucking idea why steam doesn't support case sensitive volumes on OS X when it does so on Linux ... regardless of the fact that everyone else for OS X except Adobe and Valve
Steam - because
Adobe * - Because according to Adobe the Apple development toolchain doesn't work right and so they can't support case sensitivity
Re: (Score:2)
Some developers use shared file systems on CIFS, whether Microsoft file server or Samba based. Some of us also inherit code that uses mixed case that maps to the same file name when made single case for legacy reasons: I can name several old UNIX programs that do not compile on CygWin without considerable revision of their source code, due to precisely this sort of issue.
Mac OS X does support case-sensitive filesystems (Score:5, Informative)
Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.
However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...
Re: (Score:2)
So does Windows, though you may confuse the Win32 API if you use it. NTFS is case-preserving and the native APIs are case-sensitive. Win32 functions can use FILE_FLAG_POSIX_SEMANTICS to require case-sensitivity, and Interix (Microsoft's POSIX-on-NT environment that runs in the Subsystem for Unix Applications or SUA) does so by default. I don't know of any way to make Win32 case-sensitive by default without doing some kind of crazy hooking of the relevant APIs or installing a filter driver to enforce it.
Re: (Score:3)
Keep in mind that Mac OS X supports case-sensitive HFS+ filesystems, and has done so from Mac OS X 10.3 on (2003). All you have to do is create a partition with that particular flavour of HFS+.
Stepping back from HFS+ they've even supported case-sensitive file systems long before that since you could use UFS on OS X. Even OS 9 supported it but I don't remember if you could boot that from it.
However, Adobe refuses to support case-sensitive filesystems. The Photoshop installer refuses to install on a case-sensitive filesystem, and Lightroom geolocation support is broken on case-sensitive filesystems, and always has been. Of course this limitation is not documented in their sales documentation, and the official fix is to reformat the partition...
Yep. The Adobe suite won't even open files over NFS.
Re: (Score:2)
I've never been able to make much sense of Adobe's stance in this, but as far as I can tell Adobe thinks that case-sensitive file systems are useless and if they wait long enough they will go away.
I vaguely remember that one version of Photoshop failed on case-sensitive volumes, and there was a patch circulating that fixed about 9 filenames scattered throughout the code, and solved the problem. Rather than applying this patch, Adobe chose to block installation on case-sensitive volumes in modern versions.
"Critical Git" Security Vulnerability Announced? (Score:2)