| Date: | November 4, 2010 / year-entry #310 |
| Tags: | other |
| Orig Link: | https://blogs.msdn.microsoft.com/oldnewthing/20101104-00/?p=12353 |
| Comments: | 33 |
| Summary: | First, the story as told by others: Information about Windows Vista Multilingual User Interface (MUI) What the %$#& is up with localized paths in Vista? Here is what's up with localized paths in Vista (and in Windows!) If you had gotten there first, you might have staked your claim too! Making things better out from... |
First, the story as told by others:
Now the question you're all going to ask so I may as well answer it: Why is this information kept in a First answer: Because alternate streams require NTFS. Localized names were introduced in Windows 2000, and Windows 2000 gave you the option of formatting your drive as FAT or NTFS. (It wasn't until Windows Vista that NTFS became mandatory.) Therefore the mechanism for localized names needed to work when your drive was formatted as FAT. Okay, fine, maybe you tell people, "Sorry, this feature requires NTFS." All those multinational corporations who use FAT-formatted drives in the year 2000 are screwed. Well, placing the information in an alternate data stream means that each file would have to be accessed just to get its name. Remember, it's more efficient when you buy in bulk. Consider a directory with 500 files. A simple directory listing like one provided by You increased the number of I/O requests by a factor of over 200. And when you are looking at files on a slow network (hello, multinational company with servers all over the world), that factor can be deadly. Suppose the ping time to the server is 500ms. The On the other hand, if all the localized names are placed in a single file, then the I/O count is only 10: open directory, five "give me the next 100 files", close directory; open Okay, maybe you tell people, "Sorry, this feature requires a high-speed network." All those multinational corporations with servers around the world are screwed. The theoretically highest-speed network connection between New York and Tokyo has a 72ms ping time because that's how fast it takes light itself to travel that distance and back. Your 500-file directory takes nearly two minutes to display. Seeing as multinational corporations were the initial target audience for the MUI feature (since they're the ones who are most likely to have users with different language preferences), designing your feature so that your target audience can't use it seems like a pretty bad execution plan. A file's name is traditionally considered metadata, and traditionally, metadata is visible without requiring access to the file. A file can show up in a directory listing even though you don't have access to it. But if the file's localized name is stored in the file itself, you now have the situation where you don't even know the name of the file because you can't access it. This is even worse than I'm sorry, you don't have permission to know where this shortcut file should show up in the Explorer window. This would be I'm sorry, you don't have permission to know the name of the file in this directory listing. Remember that reading from an alternate data stream triggers a recall if the file had been archived to tape. You don't want to have to restore an entire directory from tape just because somebody opened the folder in Explorer. And finally, alternate data streams are very fragile. Any tool that processes a file has a decent chance of inadvertently destroying the alternate data streams. (And good luck if your backup program doesn't preserve the alternate data streams.) |
Comments (33)
Comments are closed. |
So… why not add enhancements to FAT and NTFS and contain the localization info in the metadata? :)
@Vilx-
That was my basic thought too. I'm not familiar with these formats, but I imagine that at this point it would be an unholy nightmare to try to add to these long-established specifications. It might be nice to add this in the next incarnation of Windows, however.
As far as the rename a copy issue goes, IIRC desktop.ini's have a DeleteOnCopy section that would have stripped the name if some tool other than robocopy had been used I'm guessing
I remember reading on TDWTF about those IT bosses who seriously thought FAT is more secure/stable than NTFS.
And archived files. Seriously, why this marginal feature even deserves mentioning. Last I heard, it's phased out. The whole tape support is being phased out. Good riddance.
"Seriously, why this marginal feature even deserves mentioning. Last I heard, it's phased out"
The situation in the year 2000, however, was probably different
I'm really curious as to how many people have ever used a file archived to tape. I'd never even heard of that feature until I started reading this blog.
Because, quite frankly, applications should solve application problems in application code, not go running to the file system team for everything they want to do.
@Adam Rosenfield: My client site archives all the network drives to tape every day. Restore from tape isn't common, and it's usually single files that need to be restored. But there have been cases of several GB of data being requested from archives because someone deleted an entire folder and nobody noticed for 4 months. Tapes are a lot cheaper to purchase compared to hard drives. Our tapes aren't going anywhere anytime soon.
That said, the tapes aren't available as a network drive though. As far as I know they're stored in a box somewhere with a date written in sharpie on the outside. Data is required to be kept for something like 7 years. Somewhere there's a big room full of boxes.
I have another solution: Leave file names English-only and teach users accordingly. Deep down below, the files are still named in English (or in the first language that was installed, which is worse), no matter what desktop.ini says; and sooner or later this fact will manifest itself to the user, in the most inconveniencing way if the user is not prepared.
Not withstanding the NTFS vs. FAT argument, couldn't a lot of the arguments about alternative streams be dealt with by putting the localized names in an alternate stream of the directory itself? Now, you have two reads (directory in English, directory in localized language), instead of the 500 or whatever number Raymond uses. Further, it seems like a logical extension — the name of the file is kept in the directory, the localized name of the file is kept in (the localization stream of) the directory.
@Adam Rosenfield: Yes, many of our customers archive hundreds of gigabytes of medical images to tape.
That's not archive, it's backup. Tape is still very suitable for backup in a lot of cases, but what's being talked about here is a HSM solution where older data gets pushed off to slower secondary media.
What I still don't get (after skimming the articles) about the localized dir names is the following:
On German Vista/7 explorer shows "C:Programme" while cmd shows "C:Program Files". So far so good.
Editing the text in the explorer bar (i.e. going from bread crumb to edit) shows the english names again. But here comes the catch: The autocompletion after entering e.g. "C:Pro" only suggests the German name and then does not work. Explorer fails to accept its suggested input of "C:Programme".
Is this a PEBKAC situation, a bug or a "feature" by design?
"I have another solution: Leave file names English-only and teach users accordingly"
Seriously? I'm an English-only speaker so that would work for me, but if you were to change that sentence to say "Leave file names Japanese-only and teach users accordingly" I would be quite upset at windows. imagine seeing a bunch of strange Japanese characters trying to remember which series of wingdings within the list of 500 my report is in.
@Me: I'd say it's a bug. Explorer doesn't recognise it if you type in the translated name – looks like they "forgot" about that particular case.
@Joshua Ganes "It might be nice to add this in the next incarnation of Windows, however." The F/OSS Conspiracy theorists would have a field day with something like that. I can just see the headlines now "Microsoft takes another victim in its EEE strategy".
@Me, @JonPotter: I think it's mostly intentional, actually, albeit a little confusing.
In XP, localisation was done by physically changing the folder names (so a German installation of Windows would actually have C:Programme on disk, and there would be no C:Program Files). One of the problems with this is that if you switched UI languages then the folder names wouldn't change, which would confuse people using the same PC with multiple users, each running their own language (admittedly, not common, but as Raymond said, this is intended for those big multinational companies — think about remote login servers for a moment). The other problem with it is that stupid software didn't think to check the folder name and assumed it would always be called C:Program Files, and thus broke horribly on localised PCs. (And again, some would say "and they deserve to", but the big companies wouldn't look favourably on an OS upgrade that stopped their old and crusty LOB apps from working.)
In Vista/7, it was changed so that the name on disk is fixed, but the displayed name varies according to whatever the current name at the moment is. This fixes both of the problems from before, but introduces an odd disconnect — pathnames (which is what you're editing if you click into the address bar and start typing) use the on-disk paths, but the breadcrumbs themselves (and the folder view) shows the localised name. Windows doesn't actually have a way to represent a path using the localised names — paths are always physical.
An interesting quirk of this is that if you navigate through to some folder under a localised location (eg. the breadcrumb bar shows C: > Programme > Some App), and then click into the bar to switch to path editing, then the display will change to the physical path (eg. C:Program FilesSome App). Then when you click out again it'll change back.
Yes, it's a bit weird. But if you think about it, you'll see why the autocomplete won't work on the localised names — and it's the same reason as discussed in this post.
[Disclaimer: I have no connection to MS, so I don't know if this is the "real" reason or not. But it makes sense to me.]
@Miral: I agree, in part, but if you re-read Me's original post you'll see that the main problem is that the autocomplete actually completes the localised names. If you type C:Prog on a German system, it will auto-complete as in C:Programme, NOT c:Program Files. So if nothing else I would say that definitely is a bug – what's the point of auto-completing a path that won't be recognised when you press return?
@Frode Aarebrot:
Those are backups, not offline files. In 2010 it's time to get with the program already and use "snapshots" (or "previous versions") feature of NTFS. Available like since 2005 or so.
And I don't think it's possible to buy 2TB of uncompressed tape space for $150.
The English names on disk, localized names in (most) UI is really confusing – I've had several users complain that my (pre-Vista) program showed different paths than Explorer, and once this was fixed that the directory listing shows one thing, but the text box requires something else (this even confused me for a when I first encountered it).
Yes, in 2010 people do still use archive to tape solutions. If you don't think so, just write an enterprise indexing solution that doesn't respect the archive bit and see how fast those hot fix request start popping in as you drag hundreds of thousands of files back off of tape.
"Editing the text in the explorer bar (i.e. going from bread crumb to edit) shows the english names again. But here comes the catch: The autocompletion after entering e.g. "C:Pro" only suggests the German name and then does not work. Explorer fails to accept its suggested input of "C:Programme"."
Actually, I just tried on German Windows 7 x64. Entering "C:Pro" suggests both "C:Programme" and "C:Program Files" (and the corresponding x86 versions) and all of them work. Entering "C:Ben" also suggests "C:Benutzer", which leads to "C:Users". So on my system it works like it should (with one exception: For some stupid reason, I have a real "C:Programme" folder, so entering that into the bar will lead to this one, not to "C:Program Files").
@Alex Grigoriev
http://www.ukofficedirect.co.uk/sony-800-1600gb-lto-4-prd_368794.aspx
800GB uncompressed for about £30 == about $50, so 2.4TB for the $150 you suggested. Admittedly not a big saving over disks, but probably more reliable for long term storage situations.
Is it not so that this feature has created more problems than it has solved?
@Vilx: Yes, it is not so.
Everytime I have a new account on a Vista/Win 7 machine the first thing I do is go through all of the directories under %UserProfile% and delete the LocalizedResourceName line from all of the Desktop.ini files.
If I understand correctly,
* for directories, the localized name is in the directory itself's Desktop.ini file,
* while for files, the localized name is in the parent directory's Desktop.ini file?
Is there a registry hack to disable showing localized names?
Makes sense. Taking a guess: this is what killed WinFS?
@Frode Aarebrot:
I agree with Alex: Hard drives are cheaper than tapes nowadays, on a cost per byte basis.
@Frode Aarebrot:
Well, that link shows tape at a 50% discount, so if you compare suggested retail price, disk is cheaper.
Two things: Firstly (and less importantly), I'd have thought that dynamically translating folder names made it harder to give users reliable instructions. I can't tell people to look in `Program Files', for example, because that folder might have a different name for the reader — even (now) that we actually use the same machine. Given that Microsoft doesn't do these sorts of things lightly, does anyone know what the costs of this problem actually are relative to the obvious benefits of having things in users' preferred languages? (The Unix approach is simply for the main system directories to have runic names which are more or less incomprehensible to everyone.)
Secondly, I'll dispute Raymond's analysis of the network server case: he makes a classic confusion of latency versus throughput. I'm sure that CIFS is capable of pipelining requests, so we should be counting only necessary round trips: one for the directory contents and two (open and read, respectively concurrent!) for each of the files' alternate name streams. Raymond's other reasons seem sound, though.
Tell them to look in C:PROGRA~1 then :)
Are there 3 different names for Program Files?
Progra~1, Program Files, and localized. Insane!
Why not store the non-localized LFN at the same place as the localized LFN?