MotoCache1
Chief Droid Scientist
In this guide I'm going to cover how and why to unhide "known file extensions" in Microsoft Windows. Supporting Microsoft Windows "features" is a good bit outside of the primary mission here in the Droid Labs, but this particular one so frequently causes trouble that I decided it had to be done.
Note: If you don't really understand filenames and directories and extensions and such (and maybe even if you think you do, but aren't sure), jump down to the bottom, read the "A (not so) brief education in some related concepts" section and then come back here. That will help avoid you being lost just due to terminology issues.
OK, so on with it...
I'm not completely sure when Microsoft started this insanity, but at some point after Windows NT Microsoft decided its users were too stupid to handle file names with extensions and that it would be better if Windows kept the extensions out of users hands by hiding them if they were "well known" (like .exe, .zip, .txt, etc.). If I had to guess it was because they got tired of making all that money answering support phone calls (they charge for support) when some noob renamed "Instructions.txt" to "My Instructions" (with no extension) and then discovered it was "broken" because double clicking on it failed to load the file up in Notepad like it had before. Regardless of the factual basis for the decision, at this point all Microsoft Windows end user OS's ship defaulted to what I call "dummy mode" where the file extensions are hidden. Personally I think this is a horrible trojan horse risk because clever evildoers can make a .exe file with an icon set to look like Notepad's icon and then the unwary user thinks they are opening a text file when they are really running an executable. Sure Windows will warn them they are running an executable when they click it, but honestly, if they can't be trusted to see their file extensions, are they really going to read that warning and attach any significance to it? But I digress.
Anyway, what does this have to do with all of us, and specifically our purpose here in Droid Labs? Well, a lot of what we do here is messing with custom recovery packages that you install on your phone. These are ".zip" files and if you are running SPRecovery, then whatever the name of the file was when you got it, when you put it on your phone it needs to be specifically named "update.zip" in order for SPRecovery to find and run it. And therein lies the problem. Say the file is sitting on your computer as "RootMyPhone.zip" and you need to copy it to SD card and have it named "update.zip" (not Update.zip, or UPDATE.zip or update.ZIP either by the way, but that's a separate issue).
The usual, more non-geek friendly procedure for getting this file to your SD card goes something like this:
You see, unless you have already changed the default, after you copy the file to the phone, it will look like this in Windows:
So when you rename it, if you don't understand anything about file extensions, you're going to follow directions and rename it and type in "update.zip" for the new name -- making it look like this:
Of course you've not done what you thought you were doing at all because Windows was "helping" you by making sure that you couldn't change the file extension. So what you really did was rename the file from "RootMyPhone.zip" to "update.zip.zip". If we turn off the stupid "hide extensions for known file types" setting we can see our error:
Well, "update.zip.zip" and "update.zip" sure aren't the same thing, so of course SPRecovery is not going to find your file and you're going to get an error and be lost and confused.
If you'd had "hide extensions for known file types" turned off at the outset it would have looked like this when you first copied the file:
Then, when you renamed the file and typed in "update.zip" for the new name, although it would look the same as it did back when you had extensions hidden (and it was named wrong), now it actually has the right name.
As a side note, I don't actually use the "icons" view shown in these screen shots - I only used that mode here because that it eliminates extraneous information and because I know a lot of people do use that mode. I use the "Details" mode (View, Details) which lets you see more information about the file and looks like this:
If for no other reason than those presented above, I think every person who is even slightly above "helpless end user" should turn off "hide extensions for known file types" and then just don't go changing the extension of a file unless you know what you're doing and are doing so for a good reason. Anybody that is not even slightly above "helpless end user" hopefully isn't here reading this guide, much less tampering with the guts of their phone.
Hey, you're probably running a rooted phone -- the least you could do is know the real names of the files on your PC, right?
OK, so if you're convinced and tired of hearing me yammer about it, here's how you do it. It's easy and you can always set it back if you hate it.
Windows XP (yes, even my beloved XP defaults to dummy mode)
Windows Vista and Windows 7
There. You should never suffer with not knowing what you've named a file again. Don't you feel better?
You don't read to need the section below unless any of the above confused you.
A (not so) brief education in some related concepts
Some terminology:
Given a file whose complete name is:
name - the name is the portion of the complete file name that follows the last backslash. In our example, the name would then be "BootAnimation.zip".
basename - the basename is a portion of the name. It is the portion up to, but not including the last period in the name, and whatever follows it. So, for the name "BootAnimation.zip", the basename is "BootAnimation".
extension - the extension (sometimes called the suffix, but not usually in a Windows context) is the portion of the name which follows the last period in the name (if the name contains a period). If the name does not contain a period then it has no extension. This is fairly uncommon in Windows, but very common in Linux (for reasons discussed elsewhere in this guide). So, for the name "BootAnimation.zip", the extension is "zip" -- or some would say ".zip" (pronounced "dot zip").
Some key differences between Windows and Linux file names:
While Windows and Linux both feature complete file names that contain a path, a name, and optionally an extension, there are numerous differences between the way the two environments use file names.
1. A complete Windows file name begins with a "drive letter" while a Linux complete file name does not (Linux uses "mount points" to make different devices or partitions appear as though they are merely one of the many directories contained in the root directory of the system).
2. Windows uses backslashes ("\") to separate directory names in a path while Linux uses front slashes ("/").
3. Files in Windows almost always have an extension whereas in Linux, files with no extension are common. The reason for this is that in a Windows system the extension is what tells the Operating System (OS) what type of file it is and how to handle it. For non-executable files, the OS generally decides what to do with it by looking the extension up against a list of "file type associations" to see what executable should be used to open that file. Linux however looks inside the file to determine what type of file it is. If a file is not an executable and needs another file to "handle" it, a header in the file will specify the executable that should be used.
4. File names are not "case sensitive" in Windows but they are in Linux. This means that if you have a file named "c:\data\droid\RecoveryPackages\BootAnimation.zip" in Windows, you can refer to it as "C:\DATA\DROID\RECOVERYPACKAGES\BOOTANIMATION.ZIP" and Windows will still find it. It also means then that you cannot have two files whose names differ only in their capitalization in the same directory in Windows. In other words, in a given directory you can't have an "abc.zip" and an "ABC.zip" -- to Windows those would both be the same file. In Linux however, if you have a file named "/sdcard/SomeFile.txt", you must enter the name capitalized exactly as shown or Linux will not find it. In Linux you absolutely can have an "abc.zip" and an "ABC.zip" (as well as an "aBc.zip" and every other permutation) in the same directory.
5. Windows and Linux handle spaces inside file and/or directory names differently. Spaces in file names are not much of an issue when opening and closing files through a Graphical User Interface (GUI) as you are picking the file explicitly from a list and the only piece of information involved is its name. But in Linux (and Windows too if you're an old fart like me, or a true geek) a lot of work is done at the command line where the OS must parse what you've typed and decide what part of it is the command and what part is a parameter and where each of those sub-strings within what you've entered begins and ends.
Consider this Windows command line command: type test file.txt
If you enter that command, expecting to output the contents of the file "test file.txt" to the screen, you might be surprised when you get this output instead:
The correct way to do this is to type the command like this: type "test file".txt
By putting "test file" in quotes the parser knows that is all part of the basename. You could also do this: type "test file.txt"
That second example however is not as universally correct because it succeeds for a different reason (one that is not universally applicable). The second example succeeds because having quotes around the entire string tells the parser "this is all one single parameter to be passed to the type command". When you start dealing with spaces inside of directory names in paths, and more complex issues, you should find that quoting just the directory name or basename that contains the space is universally functional. More complex example of a command against a file with a path containing spaces and a name containing spaces, properly quoted for use at the command line:
Note: If you don't really understand filenames and directories and extensions and such (and maybe even if you think you do, but aren't sure), jump down to the bottom, read the "A (not so) brief education in some related concepts" section and then come back here. That will help avoid you being lost just due to terminology issues.
OK, so on with it...
I'm not completely sure when Microsoft started this insanity, but at some point after Windows NT Microsoft decided its users were too stupid to handle file names with extensions and that it would be better if Windows kept the extensions out of users hands by hiding them if they were "well known" (like .exe, .zip, .txt, etc.). If I had to guess it was because they got tired of making all that money answering support phone calls (they charge for support) when some noob renamed "Instructions.txt" to "My Instructions" (with no extension) and then discovered it was "broken" because double clicking on it failed to load the file up in Notepad like it had before. Regardless of the factual basis for the decision, at this point all Microsoft Windows end user OS's ship defaulted to what I call "dummy mode" where the file extensions are hidden. Personally I think this is a horrible trojan horse risk because clever evildoers can make a .exe file with an icon set to look like Notepad's icon and then the unwary user thinks they are opening a text file when they are really running an executable. Sure Windows will warn them they are running an executable when they click it, but honestly, if they can't be trusted to see their file extensions, are they really going to read that warning and attach any significance to it? But I digress.
Anyway, what does this have to do with all of us, and specifically our purpose here in Droid Labs? Well, a lot of what we do here is messing with custom recovery packages that you install on your phone. These are ".zip" files and if you are running SPRecovery, then whatever the name of the file was when you got it, when you put it on your phone it needs to be specifically named "update.zip" in order for SPRecovery to find and run it. And therein lies the problem. Say the file is sitting on your computer as "RootMyPhone.zip" and you need to copy it to SD card and have it named "update.zip" (not Update.zip, or UPDATE.zip or update.ZIP either by the way, but that's a separate issue).
The usual, more non-geek friendly procedure for getting this file to your SD card goes something like this:
- Attach phone to computer via USB
- Tell phone to "mount" to allow copying of files to and from your computer
- Copy file from your computer to the drive letter that is your phone
- Rename the file on the phone to update.zip
You see, unless you have already changed the default, after you copy the file to the phone, it will look like this in Windows:
If you'd had "hide extensions for known file types" turned off at the outset it would have looked like this when you first copied the file:
As a side note, I don't actually use the "icons" view shown in these screen shots - I only used that mode here because that it eliminates extraneous information and because I know a lot of people do use that mode. I use the "Details" mode (View, Details) which lets you see more information about the file and looks like this:
Hey, you're probably running a rooted phone -- the least you could do is know the real names of the files on your PC, right?
OK, so if you're convinced and tired of hearing me yammer about it, here's how you do it. It's easy and you can always set it back if you hate it.
Windows XP (yes, even my beloved XP defaults to dummy mode)
- Click Start
- Settings
- Control Panel
- Folder Options
- Click the "View" tab
- Scroll down a little and uncheck "Hide extensions for known file types"
- Click OK
Windows Vista and Windows 7
- Click Start
- Control Panel
- Appearance and Personalization
- Folder Options
- Scroll down a little and uncheck "Hide extensions for known file types"
- Click OK
There. You should never suffer with not knowing what you've named a file again. Don't you feel better?
You don't read to need the section below unless any of the above confused you.
A (not so) brief education in some related concepts
Some terminology:
Given a file whose complete name is:
c:\data\droid\RecoveryPackages\BootAnimation.zip
path - the path is the first part of the complete name which identifies the path one travels through the nested subdirectories to find the file. In Windows, a local path ("c:") followed by zero or more directory (also called "subdirectory") names. In this case we must traverse 3 directories to reach our file. In the root of the c: drive (the topmost, or lowest level depending upon how you visualize directory trees) we find the "data" directory. Inside that directory we'll find the "droid" directory. Inside that directory is the "recovery_packages" directory, and within that directory (finally) we find the file "MC1_TATDYLF_Boot_Animation.zip". So, the "path" to this file is the "c:\data\droid\RecoveryPackages\" part. Technically the "trailing slash" (the last backslash in that string) should be used when referring to the path as that is what positively identifies that the last name in the string ("RecoveryPackages") is a directory and not a file. That said, practices vary as to whether a given application that asks for a path name expects the trailing slash. If you're ever asked for a path name and then the application builds a complete file name from it and it looks like this "c:\data\droid\RecoveryPackages\\BootAnimation.zip" then the developer that wrote the app assumed you would not be providing the trailing slash and added it when concatenating the file name to the path you provided. Windows is generally tolerant of this unless it happens at the beginning of the path (because a double backslash at the beginning of a path has a special meaning to Windows).
name - the name is the portion of the complete file name that follows the last backslash. In our example, the name would then be "BootAnimation.zip".
basename - the basename is a portion of the name. It is the portion up to, but not including the last period in the name, and whatever follows it. So, for the name "BootAnimation.zip", the basename is "BootAnimation".
extension - the extension (sometimes called the suffix, but not usually in a Windows context) is the portion of the name which follows the last period in the name (if the name contains a period). If the name does not contain a period then it has no extension. This is fairly uncommon in Windows, but very common in Linux (for reasons discussed elsewhere in this guide). So, for the name "BootAnimation.zip", the extension is "zip" -- or some would say ".zip" (pronounced "dot zip").
Some key differences between Windows and Linux file names:
While Windows and Linux both feature complete file names that contain a path, a name, and optionally an extension, there are numerous differences between the way the two environments use file names.
1. A complete Windows file name begins with a "drive letter" while a Linux complete file name does not (Linux uses "mount points" to make different devices or partitions appear as though they are merely one of the many directories contained in the root directory of the system).
2. Windows uses backslashes ("\") to separate directory names in a path while Linux uses front slashes ("/").
3. Files in Windows almost always have an extension whereas in Linux, files with no extension are common. The reason for this is that in a Windows system the extension is what tells the Operating System (OS) what type of file it is and how to handle it. For non-executable files, the OS generally decides what to do with it by looking the extension up against a list of "file type associations" to see what executable should be used to open that file. Linux however looks inside the file to determine what type of file it is. If a file is not an executable and needs another file to "handle" it, a header in the file will specify the executable that should be used.
4. File names are not "case sensitive" in Windows but they are in Linux. This means that if you have a file named "c:\data\droid\RecoveryPackages\BootAnimation.zip" in Windows, you can refer to it as "C:\DATA\DROID\RECOVERYPACKAGES\BOOTANIMATION.ZIP" and Windows will still find it. It also means then that you cannot have two files whose names differ only in their capitalization in the same directory in Windows. In other words, in a given directory you can't have an "abc.zip" and an "ABC.zip" -- to Windows those would both be the same file. In Linux however, if you have a file named "/sdcard/SomeFile.txt", you must enter the name capitalized exactly as shown or Linux will not find it. In Linux you absolutely can have an "abc.zip" and an "ABC.zip" (as well as an "aBc.zip" and every other permutation) in the same directory.
5. Windows and Linux handle spaces inside file and/or directory names differently. Spaces in file names are not much of an issue when opening and closing files through a Graphical User Interface (GUI) as you are picking the file explicitly from a list and the only piece of information involved is its name. But in Linux (and Windows too if you're an old fart like me, or a true geek) a lot of work is done at the command line where the OS must parse what you've typed and decide what part of it is the command and what part is a parameter and where each of those sub-strings within what you've entered begins and ends.
Consider this Windows command line command: type test file.txt
If you enter that command, expecting to output the contents of the file "test file.txt" to the screen, you might be surprised when you get this output instead:
Unfortunately the command line parser saw the space between "test" and "file.txt" and assumed you wanted to view the contents of one file named "test" and then view the contents of a second file named "file.txt". So you need a way to tell the parser that the file name is actually "test file.txt".
The correct way to do this is to type the command like this: type "test file".txt
By putting "test file" in quotes the parser knows that is all part of the basename. You could also do this: type "test file.txt"
That second example however is not as universally correct because it succeeds for a different reason (one that is not universally applicable). The second example succeeds because having quotes around the entire string tells the parser "this is all one single parameter to be passed to the type command". When you start dealing with spaces inside of directory names in paths, and more complex issues, you should find that quoting just the directory name or basename that contains the space is universally functional. More complex example of a command against a file with a path containing spaces and a name containing spaces, properly quoted for use at the command line:
type c:\"Program Files"\Motorola\"RSD Lite"\"CDMA Test Commands Version9_9".tdb
In Linux, files with spaces in the name are a lot less common. You'll more often see underscores ("_") used to put some spacing in a file or directory name. For those occasions where a file with a space in the name is encountered, in Linux you can use the same quoting techniques presented above to refer to them, but there is also another way. In Linux you can tell the command parser not to treat a space as a delimiter by "escaping" it. In character based tasks, "escaping" a character means flagging the character as needing to function as a normal ASCII character, and not having some special function that is typically associated with it. In many environments (not Windows) the standard escape character is the backslash ("\") and such is the case with Linux. So if we had a file in Linux whose complete name was "/system/bin/recovery files/2010-08-31 0500.tar.gz", and we needed to refer to it at the command line, and didn't want to use quotes, we could type it like this:
/system/bin/recovery\ files/2010-08-31\ 0500.tar.gz
Since each space is preceded by a backslash, the parser will understand that the command/parameter/filename has not yet ended, but instead contains an actual space character.
