Yes, me too. The very first thing I do on a new Windows installation is to turn off that damn option to suppress the display of file name extensions.
I can’t figure out why that’s even an option, but what I really don’t get is that it’s been the Windows default setting for years. I think maybe Windows 95 was the first time I saw it.
As another veteran of 8 character file names I always use spaces today in naming. Any system that required me to put in an underscore would see it fly through a window.
I’m trying and trying and I cannot imagine any universe in which underscores would be preferred by anyone.
I use file names like Florence [SC] Evening News - Monday, October 21, 1935, p1 pt2.JPG all the time. They are as long as they need to be, so 32-64 characters are the norm. I don’t even understand your objection.
The maximum path+filename length in Windows is something like 260 characters (except when it’s 32k, but the details are technical). A 40 character filename is not a big deal, but combine it with a few 50-100 character directory entries and you have problems. The places I’ve seen people run into this is when they have a verbose filename and directory structure, and then they copy it into “Backup for January - July 2012” or some such, which pushes them over the edge. They then get weird errors, like they can see the files and copy them, but not open them.
You are far better off using a filename which is verbose enough to be descriptive to you of what the file is, than so terse that you lose things. There is a limit though.
Well, for dates I use 19351021 or maybe 1935-10-21. That way, not only are they compact, they also sort.
Yes, it is. When I find it and blow it up to get rid of all the filenames with spaces. I write Unix shell scripts, and filenames with spaces make my life difficult. I hate them and want to blow up every computer that hosts them.
They would be preferred if backwards compatibility is a consideration.
The ISO 9660 standard has some limits:
While 200 characters might not seem like a severe restriction, I have run across modern (post-Windows 3.1) programs that don’t like any more than 64 characters. I can’t remember just what those were offhand.
And your sample file name would cause problems in my 2012 version of a video server, the machine that handles broadcast files for our cable channel. Give it a comma, and it goes apeshit. It’s a Linux box inside, so that might be the reason.
There is indeed an art to the creation of file names, and integration with folders or directories is even more art. If you find yourself naming 1000 files in the same folder all beginning with “League of Women Voters…”, as a friend of mine does, Perhaps it’s time to re-think your storage and make a directory just for the League’s files. That way, you don’t have to repeat it each time and file names can be more meaningful.
And there’s nothing more annoying than to look at a filename list, most of which are 20 characters or so, and find one that’s 65. It makes the column display jump into a wide mode just for a single name, and other names cannot be displayed for lack of space without extensive scrolls. There are other places to store all that auxiliary data than a file name.
These may seem like trivial considerations, but when you work with millions of files (well, at least 50TB, not all online at once) and have to be able to find a single one on demand, the organization becomes critical.
And standingwave’s “sort” comment is also relevant.
Put me down for being of conservative philosophy about file naming conventions.
Spaces is a file name should be considered a definite BAD idea. They are commonly acceptable today, but you can never be sure just how files names will be used, or what pieces of software will or won’t work with them. (See anecdote below.)
Dots in files names likewise. These generally seem to work okay these days, but you never know when you’ll run across some app that chokes on them, as in several examples shown above.
Hyphens in file names seem to work fine. I’m not aware of any problems with this.
Underscores in file names: These work fine and always have. It’s your choice whether to use them or not. VeryLongFileName.txt or Very_Long_File_Name.txt – take your pick.
I think that names without underscores are the more popular, at least among programmers I’ve talked to, e.g., VeryLongFileName.txt – A bit of computer jargon: This is called CamelCase.
Anecdote about how odd names can cause trouble in ways you didn’t expect: Since this post is long enough, I’ll write a separate post about this.
ETA: Also beware: If there’s any chance your file will be used or transmitted to or from any machine other than your own: Beware of case conventions. Some machines (in particular, all flavors of Microsoft DOS, Winders, and similar) are case-insensitive about names. Unix, Linux, and all derivatives thereof are case-sensitive. Just keep that in mind when you choose names for files.
I have to say, the programmer in me names everything without spaces because I don’t want to have to deal with having to take the special considerations for spaces when writing scripts for myself.
Then when it comes time to actually WRITE the script I get paranoid and make sure to handle spaces anyway. :smack:
Anecdote about how oddball file names can bite you later on, in ways you maybe didn’t expect.
TRUE STORY.
A certain grocery wholesaler produces data files with product pricing information, to be downloaded by retailers (supermarkets) and imported into their cash register POS systems. There are three to eight such files each week, with longish names.
Those POS systems in the store are a cash register application, written by a small company where I used to work. This POS system is capable or running add-on modules written in a home-grown scripting language. I am fluent in that scripting language. Now I do 3rd-party consulting for a dealer (re-seller) who traffics in this POS app.
So I write an add-on script for the store manager to run, that will automate this. It consults a config file, from which it gets a list of the files to be downloaded and the local names they are to be given (since the POS app only groks old-style DOS 8.3 names). My script does these steps, basically:
– Consult the config file to get the list of name and other details of the job (like the name of the FTP site and the user-name to work with.)
– Writes DOS batch file (which it will soon run) that will, in turn, run FTP
– Writes a FTP script that FTP will run to connect to the FTP site and get those files.
– Then runs COMMAND.COM, directing it to run that DOS batch file.
– The DOS batch file, in turn, runs FTP and gives it the FTP script for its input.
This worked fine for years. Then one day, the client calls to tell me it isn’t working right.
Took a while to figure out (all this is done long distance, via verbal phone conversations). Turns out, the wholesaler added several new files to the collection to be downloaded. These new files have longer names than the earlier files, and they have spaces in them. Why? Because the wholesaler has no idea how their customers might be downloading these files, and it never occurs to them that somebody somewhere might have a problems with it!
Turns out that the file names with spaces, which I just write verbatim into the FTP script, don’t work. The FTP program treats the spaces as word separators and won’t recognize names with spaces.
The resolution? Good thing that I am in a position to modify that add-on module (since I wrote it). I modified it so that it always writes the file names into the FTP script with quotes around them. Fortunately, FTP can work with this. (For the names that don’t have spaces in them, it still never hurts to put quotes around them.)
Moral of the story: Don’t use file names with spaces, dots, or other odd-ball punctuation. You never can predict how it will be used someday later, or what problems will happen.
This!
Create your names simple and clean, especially because you never know who else will be using those names and how they will deal with them.
Write your own scripts and programs to handle odd names, as best you can, because you never know what kinds of names other users (or their programs) will throw at you.
So the thread started with a user asking a question about procedures for users. But a bunch of people say that the answer is no because of insane programmer-side technicalities which users will never encounter or care about on systems they will never need to deal with.
Users: USE SPACES IF YOU LIKE THEM
Programmers: USERS AREN’T PROGRAMMERS
I don’t care about your issues. My system is vastly superior for my needs while working on my computers. I spent years working on software and I’ve seen the other side. All the more reason I want you to stay the hell away from what I do at home.
Fine. Your computers and your files are yours to do with as you please. Note, the OP didn’t say much about what he is doing with his files or how he is using them. He didn’t say if he ever e-mails files to anybody else, or if he uploads them somewhere.
Anybody is liable to have problems like this someday. That is, anybody who ever obtains a file from somewhere else, or who sends a file to somewhere else. If you never share files with anybody, and only use your own (or other well-known) software to deal with your own files, fine. That’s nobody else’s problem.
If you EVER have a problem with spaces in file names, because you got a file from somebody else with spaces and your programs don’t deal with them, or if you ever send a file-with-spaces to somebody else and the software they use doesn’t deal with them –
Well, don’t come back whining to the Straight Dopers about it.
Exapno Mapcase, really, what’s your beef here? OP asked. Somebody answered.
As a non-programmer, though, I prefer not to use spaces in filenames because I often send emails containing the path to a file (e.g., \servername\folder1$\folder2\filename.ext). If there are no spaces in the filename, the resulting hyperlink will correctly point to the file, but any spaces will break the hyperlink. (I do know that I can use anchor text with the file path, but I like to just display the actual path.
I don’t think I’ve ever agreed with Exapno Mapcase more before.
It’s like a mechanic arguing that automakers should only equip cars with manual transmissions because they’re easier to fix.
For technical people the underscore has been used extensively when naming all of the entities and objects associated with programming(field names, routine names, program names, script names, etc.), including file names.
I use underscores extensively in file names, sometimes due to habit and sometimes because it is more readable with a separator. I never use spaces in an identifier (like a file name) but will always use them in a description.
I strongly disagree.
A space can be interpreted as a separator or as data depending on the context.
This introduces multiple problems when used in a file name:
1 - Software written with the understanding that a space is a separator (which is a perfectly valid choice to make) will not operator properly on a file name with a space.
2 - Even when the software is capable of handling spaces in file names, it can be ambiguous depending on the context. For example, if I email a list of file names that contain spaces, how does the receiver know for sure how to interpret spaces? You might think it’s obvious because there would be an extension, but not all systems require extensions and not all extensions are known.
My interpretation of this story is that your script had a bug, which you were called in to fix, and you seem indignant that some of the users had the audacity to use perfectly valid features of their OS in naming files.
It’s moot for Windows users anyway, almost every file is stored under <Drive>:\Users<User>\Documents and Settings*
Almost every program is under
<Drive>:\Program Files*
Or Program Files (x86) if you’re on a 64-bit install. Anybody on Windows who does not handle spaces in filenames is absolutely begging for inevitable trouble, even with relative file paths. You have pretty much no excuse when programming for Windows when integral, common OS file paths contain spaces.
ETA: Sorry, it looks like the structure is
\Users\My Documents
\Users\My Pictures
etc, for some reason I thought all of those were under the group folder “Documents and Settings”. The point still stands though since those have spaces.
But it wasn’t a bug when originally written. The specs changed, which made a bug where there wasn’t one before.
Not all changes can be anticipated far in advance.
:smack:
That’s <User>\My Documents and so on. That one wasn’t a case of me misremembering the path, that was stupid fingers, apologies. The point STILL holds.