I do understand it, so the only way I'll end up with a file I can't access from a Win32 process is if I deliberately create it in a Unix process.
Or use the Native API explicitly.
This behavior however means that, say, a virus scanner built on top of the Windows API can miss files; the following loop breaks:
dirscan(directory d):
for each entry f in d
if f is a directory
dirscan(f)
else
good = filescan(f)
if(!good)
return !good
Of course, that loop already breaks because of NTFS streams, but that's another issue...
No, I agree, it's not a necessary byproduct, since Win32 could just as easily not pass the case-insensitive flag to the NT APIs it calls. However, it's clearly a deliberate choice, and I can't see how it really has anything to do with NTFS.
The root of the problem I think is actually different than that. Let's say that I create "foo.txt" and "FOO.TXT" in the same directory, either through NativeAPI calls or through the POSIX subsystem Interix.
I then go into a program in the Windows subsystem and call CreateFile("foo.txt"). This goes through and calls NtCreateFile("foo.txt"), traps into the kernel, and is passed down to the file system driver (FSD) which eventually gets a call to its CreateFile major function. At this point, the NTFS FSD still gets a request for "foo.txt".
If the program calls CreateFile("FOO.TXT"), that name also reaches the NTFS FSD. In other words, we haven't lost information.
However, as an artifact of its matching algorithm, NTFS will pick the same file in both situations. (In this case, by my very limited experiments, almost certainly "foo.txt".)
It would be very possible to return the "correct" file in each instance. In other words, the search algorithm could go something like: (1) if a file with an exact case match exists, open that file, else (2) open some canonical file. Currently NTFS drops the first step, and this is entirely a "mistake" in the NTFS file name search.
In other words, the Windows subsystem could continue to not pass down SL_CASE_SENSITIVE* and be able to open any file; it just wouldn't be able to create aliases.
(* Windows subsystems need to explicitly ask for case sensitivity, as opposed to asking for case insensitivity.)
How is its approach different to Windows? Isn't it a global setting of either case-preserving or case-sensitive?
The approaches would be very similar if you could choose whether you wanted the Windows subsystem to be case sensitive or not. The fact that you can't means that 99.99% of the time you can't have case sensitivity, since everything uses the Windows subsystem.
I've never understood why people would want resource forks or alternate streams. In what way is this different than having a directory contain several files, and having applications treat a directory as their typical operating unit instead of files?
If you're saying what I think you're saying (that you should be able to treat a "file" as a traditional file and a directory at the same time), this is exactly what Reiser4 does, and is potentially a better way of thinking about how these should operate. (Reiser4 terms these "files as directories")
The problem with this approach is that you need to either break POSIX compliance or take the chance of breaking a lot of existing programs. One of the things in the stat structure tells what sort of entity is being queried; is it a directory or a file or a pipe or a special file etc. Currently normal files are marked by S_IFREG. My understanding from reading a bigass thread on the LKML from a couple years ago ("silent semantic changes with reiser4") is that returning S_IFREG for files that act as containers like this breaks POSIX compliance. I forget the exact reason, and there's a possibility that the abstract idea is okay and it's just Reiser4's approach. (Though if it's the latter case, it's very possible that it's not fixable without adding a new system call. Or changing open(2), but Unix doesn't have the same degree of luxury of changing system calls that Windows has, especially if they want to maintain binary compatibility.)
But I suspect that a lot of programs would break if you stop returning S_IFREG for regular files, which means that you "need" to use that flag for files that are also containers. (I'm envisioning that if these features could be used reliably that a large percentage of your files very well may have streams, though they may be used for only short things that extended attributes are used for now.) So that sort of sticks implementors of this between a rock and a hard place. They have to decide between breaking POSIX compliance on something that seems pretty basic, or very possibly breaking a good deal of existing applications.
Well, they don't have to be so distinguished. They do need to be lexically distinct, or else the macro processor will operate over tokens that you didn't intend, but you can use any sort of captialisation you liek for your macro names.
Right. But, doing something different (say, making a macro named "current") will sometimes cause someone 15 frustrating minutes at trying to figure out what the heck the absolutely nonsensical error messages that GCC is outputting are supposed to mean.
It's useful to have the option.
I agree with this statement as I quoted it (i.e. out of context), but I think I disagree about what it means. I think it should be the user's option whether their FS operates in a case-sensitive or case-insensitive manner, but that applications should be written to deal with either.
This may mean using a different convention for the layout for your internal organization. Or you could use some sort of archive file (like TAR) that remembers case, and route your file requests through that.
Then again, most people who want case insensitive file systems tend to use GUI file managers anyway.
I guess I'm just one of those weirdos then. In fact, it's exactly when I'm using command line stuff that it'd almost be most useFUL to have a case-insensitive file system, because it means that I'm very likely to be typing file names. If I'm in a GUI program, I'm more likely to be just selecting files using the mouse, which means I don't care about sensitivity.
As I understand it, the Unix subsystem on Windows can operate in either case-preserving mode, like Win32, or case-sensitive mode, like other Unix systems. The Win32 subsystem, however, only operates in case-preserving mode, which means Unix processes can create files that Win32 processes are unable to access.
This is correct.
Ladies and gentlemen, can you say, "security hole"?
The fact that the Windows subsystem cannot access certain files is not a necessary byproduct of the overall approach NT takes, and is instead just a byproduct of the way NTFS does case-insensitive matching. I consider this a bug in NTFS.
On the whole, then, I agree with you that people don't really want the file system itself to be case insensitive, they just want the layer above it to be case insensitive, like Win32, or at least offer case insensitivity as an option, like the Unix subsystem on Windows, but perhaps with finer granularity than a global setting.
I'll agree with you on the second, that the option of (in)sensitivity is useful (I don't think that it should be taken away; I think OS X is closest to being "right" of any OS I know), but I disagree wit the first statement, especially if it's implemented as poorly as it is in Windows/NTFS.
Here's my suggested rule: "Macros are evil. Don't use macros, unless you're in an existing project that uses them already, or you're writing in C, or you're doing something that can't be done any other way."
Okay, this is the impression I was under. Then "or to use OS X's approach, which is to have a case-insensitive Finder layered on a case-sensitive FS" isn't really a description of what OS X does, right?
What is the difference between case preserving and case sensitive ? I can't think of any at the filesystem level.
The difference is that in a FS that isn't case preserving, if I create a file "PenIsland.html" and ask for a directory listing, it may return "PENISLAND.HTML". FAT under MS-DOS was this way.
A case preserving file system that is still case insensitive will remember what case I used, so will return "PenIsland.html", but when I say "cat penisland.html" it will give me the contents of "PenIsland.html".
A case sensitive file system will give a "file not found" error in the latter case.
In other words, not preserving, preserving but insensitive, and sensitive form an ordering; it is possible to emulate ones earlier in the list with ones later in the list, but not vice versa.
The problem is not to have a cave sensitive filesystem, but to have applications allowing some case insensitive behaviour when it is useful.
I would be okay with this at a high level, but I think it should be a much stronger statement: the sensitivity should be lost by or at the usual API level. For instance, if a program calls open("Foo.txt") and there is a "foo.txt", I think that it should match the existing file unless it also uses another flag, like O_CASESENSITIVE or something. This would mean that, in general, you could issue a command like "cmd Foo.txt" and have it work (what is IMO) "correctly".
Here is the line you have to put in your.zshrc file : zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
One more reason to use zsh... one of these days I'll have to switch, even though I can't set my login shell to zsh. Maybe put a line to automatically start it in my.cshrc/.bashrc file...
But it's trivial to do a uc(SomEthIng) or the equivalent in whatever language you use to strip out case. Perl even has its "i" tag for regexes
Huh?
The point is that if I'm at a shell and make a mistake about the case, either because I'm remembering it wrong or I make a typo, I have to go fix it. What do you want me to do, go rewrite the shell so that it explicitly will perform a case insensitive search and correct things if I'm wrong?
Going the other direction, however, is impossible - the file system didn't retain the necessary information to begin with.
I'm not arguing for file systems to discard case. I think file systems should be case-preserving, which means that it remembers what case you used.
Or to use OS X's approach, which is to have a case-insensitive Finder layered on a case-sensitive FS. Typical users gets the simplicity of the former for all their day-to-day interactions, and the/. crowd can use the sophistication of the latter as they see fit.
I'm not sure how to make that work well, though I haven't used OS X. I know how Windows does it, that that prohibits ANY traditional Windows program from using case-sensitive file names. (And, as implemented, Windows's approach to mixing case sensitivity and insensitivity its bad and a security risk. Surprise...)
Can you expand on what OS X does? I know it has an option to enable disable case sensitivity, but I don't know what you mean about it layering an insensitive layer on top of a sensitive layer.
I am convinced that most people pay dearly in performance though.
Also, this will become less and less true, at least until solid state memory becomes common. Hard drive performance is not changing all that much; bandwith grows with density, but seek times more or less don't change.
Meanwhile, processors are getting more cores than application programmers typically know how to use, which means there is plenty of time for compression. Thus if you can save a seek or two by compressing files, you might actually see increased performance. This is especially true for really small files if you have a layout like NTFS where if a file is short enough it will appear entirely within NTFS's equivalent of the directory entry and inode block combined, because files that are too big to fit in there without compression but do fit with compression will lose a seek.
You can probably also gain a big advantage if you only compress files that you almost never use. If you never use them then there is no performance hit, but you get the space. For this reason having the compression support at or above the file system level (yet still providing the same file system interface to programs) as opposed to between the file system and disk can be extremely valuable.
And, you know, you can ompress files in the application or as a step in a pileline.
Doesn't help me if I can't modify the application.
A filesystem stores files and should do so fast and lean and mean. A database keeps and protects data.
Interesting, I want my file system to keep and protect data.
Perhaps someone should design a file system interface to a database. That would be fine with me.
I'm not saying that EVERY file system has to have all of these features, but it would be nice to have at least one that does that comes with Linux and is pretty much standard, and people who care about the tiny bit of extra performance can use the leaner version. (The time taken processing the transactional stuff is going to be dwarfed by the time spent going to disk when there's a buffer cache miss anyway.)
A filesystem without extended attributes does it's job well. Why break that?
Because good extended attributes adds quite a lot.
Take paper for example: The basic interface has remaned the same for ages
Post-it notes were invented in 1968. Think of them as a real-world example of extended attributes.
On the other hand, filesystems do not care about name semantics, just name uniqueness. Why add some transformation to the mix when there is zero need for it, but a significant danger in doing so?
Again, I disagree with your "zero need".
I don't think I have really ever said "man, I wish that Windows had case sensitive file systems" or "man, I'm really glad Linux has case sensitive file systems." OTOH, I *know* I have said, on multiple occasions, "damn case sensitivity."
In C++, for instance, FOOBAR is (by convention) a macro constant value, FooBar a class name, and foobar a variable
It's interesting you bring this up, because in the case of the macro, I think it's a flaw in C and C++ that macros have to be so distinguished from other constructs. But that's another debate. (In your example I also think that the macro should be named something like FOOBAR_INIT. For instance, consider the PTHREAD_MUTEX_INITIALIZER macro in pthreads.)
There is also a much more established convention in programming. For instance, the reason that your example works is because of exactly the conventions you name. Without those conventions, I would think that case sensitivity in programming languages is also a bad idea. Can you think of ANY similar conventions for file names? The fact that I don't think there are any means that when you have to come up with a file name, you have to remember the case. It means that if you're telling someone the path of a file, you have to convey the case too. It means that if you're typing a file name, there is another typo you can make per character. None of these are terribly insurmountable issues, but at the same time, it's just one more thing that makes Unix/Linux slightly annoying.
It's not like ANDing a string against 0x20 is particularly difficuly; even in these days of unicode, it still can't be that hard to downshift a file name.
First, keep in mind that it's not *just* anding against 0x20, you also have to check if it's in the proper range first. Using naive instruction selection on x86, you've added 5 instructions per letter comparison. (Two cmps, two branches, and the and.) It's *possible* that in 1970, this was a noticeable operation and we've stuck with it for compatibility reasons. (Both compatibility of older software and compatibility in the minds of both programming and Unix folks who tend to think that case sensitivity is the right way to do things.)
Also, under Unicode it does get rather more complicated. Things can vary because of locale. Some Unicode characters would be written out as two characters without it, for instance ß (hopefully that came out right; unicode 0x00DF) represents "ss". The capital version is "SS"; this means that capitalizing strings might change the length of the string. It also brings up things like policy questions that have to be answered, for instance if "ß" and "ss" should compare the same.
I strongly suspect that there is a "right" way to do case insensitive matching, and I think that it's well worth it to figure out what it is then do it.
For writing: None, since it is a pretty bad idea with regard to performance, fragmentation and reliability.
Yes, thank your for making the value judgment for me about what weight I want to place on each of these.
As it is, the fact that NTFS supports transparent compression made it possible to do some things I was working on my laptop without either jumping through big hoops or destroying the Linux partition. (Or buying a new drive.)
Again a very bad idea. If you need that, use a database, not a filesystem.
What if you just want files?
For instance, take Subversion. SVN supports both a file system repository database, and one using Berkeley DB. For a while, the Berkeley DB was the only one it supported. Then they added the file system one, and later made the file system database version the default option when creating a new repository. The file system's chief advantage? Berkeley DB repositories aren't portable from one system to another. Now, think about how much code and how much thinking probably went into making SVN's transactional support correct. Now, think about how much would have been needed if they could rely on a transactional file system.
Besides, what's the difference between a file system and a database?
And again, a very bad idea. In fact extended attributes are a bad idea, since they break compatibility.
The problem with not doing something because it will break compatibility is that we'll never make progress. Extended attributes/streams could be used for a whole host of useful things if they could be used nicely.
(As it is there are still enough useful things you can do without suffering compatibility problems that they would be a useful feature.)
So the filesystem should understand case semantics? Very, very bad idea. Especially if you allow Unicode filenames.
Yes, it makes the implementation more difficult. However, I think it makes the end user's experience better. And it's THAT we should be designing to, not how difficult it is to code.
Thank you for revealing the light and showing me that what I thought I knew about what I needed and wanted in an operating system is wrong. All hail Linux!
I'm not saying that NO Unix has these features, just that they are few and far between. (I will admit to not knowing that ZFS had transactions though.)
but case-sensitivity is eminently useful, and only ancient operating systems ignore case, so we keep it
The M$ practices are uniformly considered dated, wrong, dangerous and anything but mainstream.
Can you name any fully-featured file systems for Unix that provide transparent compression? How 'bout any Unix that provides transactional file system behavior? Alternate streams/extended attributes that can be read and written as files?
How many versions of Unix have case insensitive file systems? (Personally, I feel that case sensitive file systems should be considered a dated practice.)
MS didn't get all of this right; their implementation of streams and extended attributes I think is lacking from just the FS point of view, and even moreso from the UI point of view, and I could go on a bit of a rant about that. Reiser4 provides what I think is a much better model for how to handle that sort of thing.
But the others are things that I wish that Linux had. And that's just looking at the file system.
That's certainly news to me! In fact, if you understood the concept of Special Relativity, this is precisely the concept that it excludes i.e. there can be nothing that moves faster than c. I would go into explaining how this all works and why there is no luminiferous aether and Michelson-Moreley experiment and how it lead to the development of Special Relativity but it would be way outside of the scope of what I can describe here.
[*] Really unimportant sites just an easy password that's the same across all of them [*] More important, but still not critical sites use variations on a couple randomly generated pronounceable passwords; the fact they are random means that no dictionary attack will find them, while the fact that they are pronounceable makes them easyish to learn [*] Critical sites (like my bank) I either generate a random password and learn it by rote repetition, or I use PasswordSafe and store the password and then just open that each time I need it.
In general, just repeat the password over and over to yourself a dozen times a few times over the course of a couple days (you can have it written down during that window) and you'll probably get it.
After all, that's how I memorized 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0.
1.) I don't care what you do with my body after I've died, 2.) unless my death is suspicious. Then I want to be buried and preserved as best as possible, so that if the police later decide they need clues and want to exhume my body, they can.
The most damaging holes are the ones that only the bad guys know about.
And: The second most damaging holes are the ones that both the bad guys and the developers know about, but no one else does The third most damaging holes are the ones that everyone knows about The fourth most damaging holes are the ones that only the developers know about
If you reveal an exploit, you know that you are in the third state. If you do not reveal an exploit to the public, but only tell the developers, you might have made things worse by going into the second state, but you also might have made things better, by moving into the fourth state. So it isn't necessarily a good thing to publicly reveal exploits.
Here are my general thoughts. I.) If you have good evidence that an exploit is in the wild, publicly release details. [We are in case 2; by releasing the exploit, we move to case 3, an improvement.]
II.) If you would expect that if your exploit was in the wild you would see evidence of that, but you see no such evidence, do not publicly release the exploit *yet*. [We are in case 4; releasing the exploit would move us to case 3, which is getting worse.] Notify the developers. If the developers are reasonably quick with a patch (I would say within a couple weeks in general, maybe until the next "Patch Tuesday" in MS's or similar cases), still do not publicly release the exploit yet. Give maybe a week after the patch is released for security-conscious users and admins to apply it. Then you may release an exploit. If the developers are not being responsive after a reasonable amount of time has passed, release the exploit at that point. Continually monitor for evidence of the exploit being used in the wild; if such evidence surfaces, release the exploit immediately.
III.) Otherwise (if you can't tell if the exploit is in the wild), do not publicly release the exploit *yet*. Follow the procedure in II, but an expedited version of it. (In other words, be more impatient.) Give a few days instead of a couple weeks, don't wait for the next Patch Tuesday unless it's right around the corner, and only give a day or two after the patch release instead of a week for people to catch up. This is the situation where we can't tell if we are in case 2 or case 4; not releasing immediately tries to minimize the chance/effect of moving from case 4 to case 3, while moving quickly tries to minimize the chance/effect of moving from case 2 to case 3.
The timing in II and III above can vary according to the severity of the bug and how hard it would be to patch, and also whether there is a workaround. If there is a workaround, both situations (*especially* III) should be biased towards releasing the exploit; if there is no workaround and it requires a patch from the vendor, the situation should become biased towards not releasing the exploit. Also, if you can release information about the vulnerability (such as a suggested workaround) without releasing enough information to be of much help to black hats, then that obviously becomes biased towards releasing that information. In fact, you might immediately release such information as this even in II. Perhaps the vendor's history as to patching behavior should come into play too.
It's very much a case-by-case scenario. Saying "always release" or "never release" I think is always wrong.
I'm a CS department, and our XP install is already customized a lot. (Custom GINA, OpenAFS set up, etc.) So it's probably the case that this policy has been non-default since the beginning.
I checked my laptop which has a mostly clean XP installation, and it was set to just admin, so that probably wouldn't work there.
Thanks for the info though; I'll have to remember that.
I've run Visual Studio 6 and 2005 under XP with non-admin rights (in fact I do it regularly), and am able to debug just fine. This includes attaching a debugger to another process.
The only thing I've done with admin priv. on here is install/uninstall programs, and haven't run into a problem yet.
Don't know anything about an option though; maybe it's set in the standard install we use here.
unless you want Windows to be constantly scanning e.g. the Program Files folder for changes... but something tells me, you wouldn't appreciate that;-)
Windows supports a directory change notification; an application can request that the file system inform it when the contents of a directory change. (Linux and some Unices has this too, but in general it's not portable across versions of Unix or at all between Linux and Windows.)
At most you'd have to scan on first boot (and that's only necessary if you don't trust the file system to stay the same between boots), even if you take this approach and don't try to think of another way entirely to do it.
*Note that many of the problems associated with multiple users on a single WINDOWS system would be at least mitigated by introducing a "home" folder. This would have been an obvious feature to implement in Vista, but no such luck.
Um, what do you think that C:\Documents and Settings\[user name] is?
Slashdot Mirror
Or use the Native API explicitly.
This behavior however means that, say, a virus scanner built on top of the Windows API can miss files; the following loop breaks: Of course, that loop already breaks because of NTFS streams, but that's another issue...
No, I agree, it's not a necessary byproduct, since Win32 could just as easily not pass the case-insensitive flag to the NT APIs it calls. However, it's clearly a deliberate choice, and I can't see how it really has anything to do with NTFS.
The root of the problem I think is actually different than that. Let's say that I create "foo.txt" and "FOO.TXT" in the same directory, either through NativeAPI calls or through the POSIX subsystem Interix.
I then go into a program in the Windows subsystem and call CreateFile("foo.txt"). This goes through and calls NtCreateFile("foo.txt"), traps into the kernel, and is passed down to the file system driver (FSD) which eventually gets a call to its CreateFile major function. At this point, the NTFS FSD still gets a request for "foo.txt".
If the program calls CreateFile("FOO.TXT"), that name also reaches the NTFS FSD. In other words, we haven't lost information.
However, as an artifact of its matching algorithm, NTFS will pick the same file in both situations. (In this case, by my very limited experiments, almost certainly "foo.txt".)
It would be very possible to return the "correct" file in each instance. In other words, the search algorithm could go something like: (1) if a file with an exact case match exists, open that file, else (2) open some canonical file. Currently NTFS drops the first step, and this is entirely a "mistake" in the NTFS file name search.
In other words, the Windows subsystem could continue to not pass down SL_CASE_SENSITIVE* and be able to open any file; it just wouldn't be able to create aliases.
(* Windows subsystems need to explicitly ask for case sensitivity, as opposed to asking for case insensitivity.)
How is its approach different to Windows? Isn't it a global setting of either case-preserving or case-sensitive?
The approaches would be very similar if you could choose whether you wanted the Windows subsystem to be case sensitive or not. The fact that you can't means that 99.99% of the time you can't have case sensitivity, since everything uses the Windows subsystem.
I've never understood why people would want resource forks or alternate streams. In what way is this different than having a directory contain several files, and having applications treat a directory as their typical operating unit instead of files?
If you're saying what I think you're saying (that you should be able to treat a "file" as a traditional file and a directory at the same time), this is exactly what Reiser4 does, and is potentially a better way of thinking about how these should operate. (Reiser4 terms these "files as directories")
The problem with this approach is that you need to either break POSIX compliance or take the chance of breaking a lot of existing programs. One of the things in the stat structure tells what sort of entity is being queried; is it a directory or a file or a pipe or a special file etc. Currently normal files are marked by S_IFREG. My understanding from reading a bigass thread on the LKML from a couple years ago ("silent semantic changes with reiser4") is that returning S_IFREG for files that act as containers like this breaks POSIX compliance. I forget the exact reason, and there's a possibility that the abstract idea is okay and it's just Reiser4's approach. (Though if it's the latter case, it's very possible that it's not fixable without adding a new system call. Or changing open(2), but Unix doesn't have the same degree of luxury of changing system calls that Windows has, especially if they want to maintain binary compatibility.)
But I suspect that a lot of programs would break if you stop returning S_IFREG for regular files, which means that you "need" to use that flag for files that are also containers. (I'm envisioning that if these features could be used reliably that a large percentage of your files very well may have streams, though they may be used for only short things that extended attributes are used for now.) So that sort of sticks implementors of this between a rock and a hard place. They have to decide between breaking POSIX compliance on something that seems pretty basic, or very possibly breaking a good deal of existing applications.
Well, they don't have to be so distinguished. They do need to be lexically distinct, or else the macro processor will operate over tokens that you didn't intend, but you can use any sort of captialisation you liek for your macro names.
Right. But, doing something different (say, making a macro named "current") will sometimes cause someone 15 frustrating minutes at trying to figure out what the heck the absolutely nonsensical error messages that GCC is outputting are supposed to mean.
It's useful to have the option.
I agree with this statement as I quoted it (i.e. out of context), but I think I disagree about what it means. I think it should be the user's option whether their FS operates in a case-sensitive or case-insensitive manner, but that applications should be written to deal with either.
This may mean using a different convention for the layout for your internal organization. Or you could use some sort of archive file (like TAR) that remembers case, and route your file requests through that.
Then again, most people who want case insensitive file systems tend to use GUI file managers anyway.
I guess I'm just one of those weirdos then. In fact, it's exactly when I'm using command line stuff that it'd almost be most useFUL to have a case-insensitive file system, because it means that I'm very likely to be typing file names. If I'm in a GUI program, I'm more likely to be just selecting files using the mouse, which means I don't care about sensitivity.
As I understand it, the Unix subsystem on Windows can operate in either case-preserving mode, like Win32, or case-sensitive mode, like other Unix systems. The Win32 subsystem, however, only operates in case-preserving mode, which means Unix processes can create files that Win32 processes are unable to access.
This is correct.
Ladies and gentlemen, can you say, "security hole"?
The fact that the Windows subsystem cannot access certain files is not a necessary byproduct of the overall approach NT takes, and is instead just a byproduct of the way NTFS does case-insensitive matching. I consider this a bug in NTFS.
On the whole, then, I agree with you that people don't really want the file system itself to be case insensitive, they just want the layer above it to be case insensitive, like Win32, or at least offer case insensitivity as an option, like the Unix subsystem on Windows, but perhaps with finer granularity than a global setting.
I'll agree with you on the second, that the option of (in)sensitivity is useful (I don't think that it should be taken away; I think OS X is closest to being "right" of any OS I know), but I disagree wit the first statement, especially if it's implemented as poorly as it is in Windows/NTFS.
The whole thing needs some usability testing.
Don't use macros. Macros are evil.
Yeah, that's a very nice theory.
Here's my suggested rule: "Macros are evil. Don't use macros, unless you're in an existing project that uses them already, or you're writing in C, or you're doing something that can't be done any other way."
Okay, this is the impression I was under. Then "or to use OS X's approach, which is to have a case-insensitive Finder layered on a case-sensitive FS" isn't really a description of what OS X does, right?
What is the difference between case preserving and case sensitive ? I can't think of any at the filesystem level.
.zshrc file : zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
.cshrc/.bashrc file...
The difference is that in a FS that isn't case preserving, if I create a file "PenIsland.html" and ask for a directory listing, it may return "PENISLAND.HTML". FAT under MS-DOS was this way.
A case preserving file system that is still case insensitive will remember what case I used, so will return "PenIsland.html", but when I say "cat penisland.html" it will give me the contents of "PenIsland.html".
A case sensitive file system will give a "file not found" error in the latter case.
In other words, not preserving, preserving but insensitive, and sensitive form an ordering; it is possible to emulate ones earlier in the list with ones later in the list, but not vice versa.
The problem is not to have a cave sensitive filesystem, but to have applications allowing some case insensitive behaviour when it is useful.
I would be okay with this at a high level, but I think it should be a much stronger statement: the sensitivity should be lost by or at the usual API level. For instance, if a program calls open("Foo.txt") and there is a "foo.txt", I think that it should match the existing file unless it also uses another flag, like O_CASESENSITIVE or something. This would mean that, in general, you could issue a command like "cmd Foo.txt" and have it work (what is IMO) "correctly".
Here is the line you have to put in your
One more reason to use zsh... one of these days I'll have to switch, even though I can't set my login shell to zsh. Maybe put a line to automatically start it in my
But it's trivial to do a uc(SomEthIng) or the equivalent in whatever language you use to strip out case. Perl even has its "i" tag for regexes
/. crowd can use the sophistication of the latter as they see fit.
Huh?
The point is that if I'm at a shell and make a mistake about the case, either because I'm remembering it wrong or I make a typo, I have to go fix it. What do you want me to do, go rewrite the shell so that it explicitly will perform a case insensitive search and correct things if I'm wrong?
Going the other direction, however, is impossible - the file system didn't retain the necessary information to begin with.
I'm not arguing for file systems to discard case. I think file systems should be case-preserving, which means that it remembers what case you used.
Or to use OS X's approach, which is to have a case-insensitive Finder layered on a case-sensitive FS. Typical users gets the simplicity of the former for all their day-to-day interactions, and the
I'm not sure how to make that work well, though I haven't used OS X. I know how Windows does it, that that prohibits ANY traditional Windows program from using case-sensitive file names. (And, as implemented, Windows's approach to mixing case sensitivity and insensitivity its bad and a security risk. Surprise...)
Can you expand on what OS X does? I know it has an option to enable disable case sensitivity, but I don't know what you mean about it layering an insensitive layer on top of a sensitive layer.
I am convinced that most people pay dearly in performance though.
Also, this will become less and less true, at least until solid state memory becomes common. Hard drive performance is not changing all that much; bandwith grows with density, but seek times more or less don't change.
Meanwhile, processors are getting more cores than application programmers typically know how to use, which means there is plenty of time for compression. Thus if you can save a seek or two by compressing files, you might actually see increased performance. This is especially true for really small files if you have a layout like NTFS where if a file is short enough it will appear entirely within NTFS's equivalent of the directory entry and inode block combined, because files that are too big to fit in there without compression but do fit with compression will lose a seek.
You can probably also gain a big advantage if you only compress files that you almost never use. If you never use them then there is no performance hit, but you get the space. For this reason having the compression support at or above the file system level (yet still providing the same file system interface to programs) as opposed to between the file system and disk can be extremely valuable.
And, you know, you can ompress files in the application or as a step in a pileline.
Doesn't help me if I can't modify the application.
A filesystem stores files and should do so fast and lean and mean. A database keeps and protects data.
Interesting, I want my file system to keep and protect data.
Perhaps someone should design a file system interface to a database. That would be fine with me.
I'm not saying that EVERY file system has to have all of these features, but it would be nice to have at least one that does that comes with Linux and is pretty much standard, and people who care about the tiny bit of extra performance can use the leaner version. (The time taken processing the transactional stuff is going to be dwarfed by the time spent going to disk when there's a buffer cache miss anyway.)
A filesystem without extended attributes does it's job well. Why break that?
Because good extended attributes adds quite a lot.
Take paper for example: The basic interface has remaned the same for ages
Post-it notes were invented in 1968. Think of them as a real-world example of extended attributes.
On the other hand, filesystems do not care about name semantics, just name uniqueness. Why add some transformation to the mix when there is zero need for it, but a significant danger in doing so?
Again, I disagree with your "zero need".
I don't think I have really ever said "man, I wish that Windows had case sensitive file systems" or "man, I'm really glad Linux has case sensitive file systems." OTOH, I *know* I have said, on multiple occasions, "damn case sensitivity."
In C++, for instance, FOOBAR is (by convention) a macro constant value, FooBar a class name, and foobar a variable
It's interesting you bring this up, because in the case of the macro, I think it's a flaw in C and C++ that macros have to be so distinguished from other constructs. But that's another debate. (In your example I also think that the macro should be named something like FOOBAR_INIT. For instance, consider the PTHREAD_MUTEX_INITIALIZER macro in pthreads.)
There is also a much more established convention in programming. For instance, the reason that your example works is because of exactly the conventions you name. Without those conventions, I would think that case sensitivity in programming languages is also a bad idea. Can you think of ANY similar conventions for file names? The fact that I don't think there are any means that when you have to come up with a file name, you have to remember the case. It means that if you're telling someone the path of a file, you have to convey the case too. It means that if you're typing a file name, there is another typo you can make per character. None of these are terribly insurmountable issues, but at the same time, it's just one more thing that makes Unix/Linux slightly annoying.
It's not like ANDing a string against 0x20 is particularly difficuly; even in these days of unicode, it still can't be that hard to downshift a file name.
First, keep in mind that it's not *just* anding against 0x20, you also have to check if it's in the proper range first. Using naive instruction selection on x86, you've added 5 instructions per letter comparison. (Two cmps, two branches, and the and.) It's *possible* that in 1970, this was a noticeable operation and we've stuck with it for compatibility reasons. (Both compatibility of older software and compatibility in the minds of both programming and Unix folks who tend to think that case sensitivity is the right way to do things.)
Also, under Unicode it does get rather more complicated. Things can vary because of locale. Some Unicode characters would be written out as two characters without it, for instance ß (hopefully that came out right; unicode 0x00DF) represents "ss". The capital version is "SS"; this means that capitalizing strings might change the length of the string. It also brings up things like policy questions that have to be answered, for instance if "ß" and "ss" should compare the same.
I strongly suspect that there is a "right" way to do case insensitive matching, and I think that it's well worth it to figure out what it is then do it.
For writing: None, since it is a pretty bad idea with regard to performance, fragmentation and reliability.
Yes, thank your for making the value judgment for me about what weight I want to place on each of these.
As it is, the fact that NTFS supports transparent compression made it possible to do some things I was working on my laptop without either jumping through big hoops or destroying the Linux partition. (Or buying a new drive.)
Again a very bad idea. If you need that, use a database, not a filesystem.
What if you just want files?
For instance, take Subversion. SVN supports both a file system repository database, and one using Berkeley DB. For a while, the Berkeley DB was the only one it supported. Then they added the file system one, and later made the file system database version the default option when creating a new repository. The file system's chief advantage? Berkeley DB repositories aren't portable from one system to another. Now, think about how much code and how much thinking probably went into making SVN's transactional support correct. Now, think about how much would have been needed if they could rely on a transactional file system.
Besides, what's the difference between a file system and a database?
And again, a very bad idea. In fact extended attributes are a bad idea, since they break compatibility.
The problem with not doing something because it will break compatibility is that we'll never make progress. Extended attributes/streams could be used for a whole host of useful things if they could be used nicely.
(As it is there are still enough useful things you can do without suffering compatibility problems that they would be a useful feature.)
So the filesystem should understand case semantics? Very, very bad idea. Especially if you allow Unicode filenames.
Yes, it makes the implementation more difficult. However, I think it makes the end user's experience better. And it's THAT we should be designing to, not how difficult it is to code.
Because PenIsland and PenisLand are two very different ideas that should not be confused.
;-)
Actually... that's a pretty good response.
Still, I argue that this is merely an argument for case preserving file systems rather than case sensitive ones.
Oh my gosh! You're so right AC!
Thank you for revealing the light and showing me that what I thought I knew about what I needed and wanted in an operating system is wrong. All hail Linux!
ZFS on Solaris10
ZFS is another file system that gets it right.
I'm not saying that NO Unix has these features, just that they are few and far between. (I will admit to not knowing that ZFS had transactions though.)
but case-sensitivity is eminently useful, and only ancient operating systems ignore case, so we keep it
Useful for what?
Knoppix has been using such a file system for years.
Really? Does it support writing?
I can't think of a less mainstream idea. Thanks, you made my day.
I bet if you carried out a survey of users you would find that case insensitivity is *exactly* mainstream.
For added evidence, I point you to OS X, which despite having some of its roots in Unix, still keeps case insensitivity by defeault.
The M$ practices are uniformly considered dated, wrong, dangerous and anything but mainstream.
Can you name any fully-featured file systems for Unix that provide transparent compression? How 'bout any Unix that provides transactional file system behavior? Alternate streams/extended attributes that can be read and written as files?
How many versions of Unix have case insensitive file systems? (Personally, I feel that case sensitive file systems should be considered a dated practice.)
MS didn't get all of this right; their implementation of streams and extended attributes I think is lacking from just the FS point of view, and even moreso from the UI point of view, and I could go on a bit of a rant about that. Reiser4 provides what I think is a much better model for how to handle that sort of thing.
But the others are things that I wish that Linux had. And that's just looking at the file system.
That's certainly news to me! In fact, if you understood the concept of Special Relativity, this is precisely the concept that it excludes i.e. there can be nothing that moves faster than c. I would go into explaining how this all works and why there is no luminiferous aether and Michelson-Moreley experiment and how it lead to the development of Special Relativity but it would be way outside of the scope of what I can describe here.
Hey wow, I can cite a few sources too.
It's not a sure thing, but a well-respected version of the big bang theory DOES have the universe expanding faster than c in a very short time.
The first item on the list is the list itself.
You don't want them to make it too easy to get, do you?
Random passwords, then just learn them.
[*] Really unimportant sites just an easy password that's the same across all of them
[*] More important, but still not critical sites use variations on a couple randomly generated pronounceable passwords; the fact they are random means that no dictionary attack will find them, while the fact that they are pronounceable makes them easyish to learn
[*] Critical sites (like my bank) I either generate a random password and learn it by rote repetition, or I use PasswordSafe and store the password and then just open that each time I need it.
In general, just repeat the password over and over to yourself a dozen times a few times over the course of a couple days (you can have it written down during that window) and you'll probably get it.
After all, that's how I memorized 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0.
(Let's see the MPAA subpoena my brain.)
I've always told people that:
1.) I don't care what you do with my body after I've died,
2.) unless my death is suspicious. Then I want to be buried and preserved as best as possible, so that if the police later decide they need clues and want to exhume my body, they can.
The most damaging holes are the ones that only the bad guys know about.
And:
The second most damaging holes are the ones that both the bad guys and the developers know about, but no one else does
The third most damaging holes are the ones that everyone knows about
The fourth most damaging holes are the ones that only the developers know about
If you reveal an exploit, you know that you are in the third state. If you do not reveal an exploit to the public, but only tell the developers, you might have made things worse by going into the second state, but you also might have made things better, by moving into the fourth state. So it isn't necessarily a good thing to publicly reveal exploits.
Here are my general thoughts.
I.) If you have good evidence that an exploit is in the wild, publicly release details. [We are in case 2; by releasing the exploit, we move to case 3, an improvement.]
II.) If you would expect that if your exploit was in the wild you would see evidence of that, but you see no such evidence, do not publicly release the exploit *yet*. [We are in case 4; releasing the exploit would move us to case 3, which is getting worse.] Notify the developers. If the developers are reasonably quick with a patch (I would say within a couple weeks in general, maybe until the next "Patch Tuesday" in MS's or similar cases), still do not publicly release the exploit yet. Give maybe a week after the patch is released for security-conscious users and admins to apply it. Then you may release an exploit. If the developers are not being responsive after a reasonable amount of time has passed, release the exploit at that point. Continually monitor for evidence of the exploit being used in the wild; if such evidence surfaces, release the exploit immediately.
III.) Otherwise (if you can't tell if the exploit is in the wild), do not publicly release the exploit *yet*. Follow the procedure in II, but an expedited version of it. (In other words, be more impatient.) Give a few days instead of a couple weeks, don't wait for the next Patch Tuesday unless it's right around the corner, and only give a day or two after the patch release instead of a week for people to catch up. This is the situation where we can't tell if we are in case 2 or case 4; not releasing immediately tries to minimize the chance/effect of moving from case 4 to case 3, while moving quickly tries to minimize the chance/effect of moving from case 2 to case 3.
The timing in II and III above can vary according to the severity of the bug and how hard it would be to patch, and also whether there is a workaround. If there is a workaround, both situations (*especially* III) should be biased towards releasing the exploit; if there is no workaround and it requires a patch from the vendor, the situation should become biased towards not releasing the exploit. Also, if you can release information about the vulnerability (such as a suggested workaround) without releasing enough information to be of much help to black hats, then that obviously becomes biased towards releasing that information. In fact, you might immediately release such information as this even in II. Perhaps the vendor's history as to patching behavior should come into play too.
It's very much a case-by-case scenario. Saying "always release" or "never release" I think is always wrong.
I'm a CS department, and our XP install is already customized a lot. (Custom GINA, OpenAFS set up, etc.) So it's probably the case that this policy has been non-default since the beginning.
I checked my laptop which has a mostly clean XP installation, and it was set to just admin, so that probably wouldn't work there.
Thanks for the info though; I'll have to remember that.
I've run Visual Studio 6 and 2005 under XP with non-admin rights (in fact I do it regularly), and am able to debug just fine. This includes attaching a debugger to another process.
The only thing I've done with admin priv. on here is install/uninstall programs, and haven't run into a problem yet.
Don't know anything about an option though; maybe it's set in the standard install we use here.
unless you want Windows to be constantly scanning e.g. the Program Files folder for changes... but something tells me, you wouldn't appreciate that ;-)
Windows supports a directory change notification; an application can request that the file system inform it when the contents of a directory change. (Linux and some Unices has this too, but in general it's not portable across versions of Unix or at all between Linux and Windows.)
At most you'd have to scan on first boot (and that's only necessary if you don't trust the file system to stay the same between boots), even if you take this approach and don't try to think of another way entirely to do it.
*Note that many of the problems associated with multiple users on a single WINDOWS system would be at least mitigated by introducing a "home" folder. This would have been an obvious feature to implement in Vista, but no such luck.
Um, what do you think that C:\Documents and Settings\[user name] is?