So at work here, they have us Macs using an NT Server to hold our work-in-progress files. One time as I was trying to copy over a file, I got this message:
When I experimented with filenames, I discovered a 32-character limit. But I didn’t discover any “invalid characters.” Are there characters that I shouldn’t use or is that just an ol’ techwives tale?
What would happen if I copy over a file that uses some punctuation or accented characters or something along those lines? What exactly are the “No-no” characters?
I would add that my personal taste in file names is more restrictive than that - you want to be able to manipulate files with scripts, use their names in URLs, store them in various places, etc, without running into escaping issues all over the place.
No, I wasn’t meaning to include the space, since it’s obviously not an illegal name character, but I agree with you. It falls into the further restrictions I alluded to in my second post.
Note also that there are certain actual names you should also avoid, for DOS legacy reasons. NUL and CON especially. They were originally directory independant names for special devices (COM1/2/3 = communications ports, LPT1 = printer, etc). Quite useful in the text based DOS world, but troublesome after the Win9x GUI. It used to be you could craft a URL that pointed to one of these places, and any hapless 9x surfer clicking on them would end up instantly bluescreening their box. (I’m almost certain I never did this to anyone. :D)
I’m not sure where you got a 32 character limit from, though. On an NTFS partition (which I presume you’re using because it could only otherwise by HPFS or FAT on Windows NT), the standard limit* for a file name is 260 characters. Here’s a comparison of file systems.
On Windows NT-family systems, if a Unicode path name begins with the prefix “\?” it can be of any length (although each individual component of the path name is still limited to 260 characters).
I had a similar problem trying to move some files on a Windows 2000 system here. The problem wasn’t the actual filename, but the whole path C:\Shared\LongFolderName\LongerFolderName\AnotherLongFolderName\LongFileName
which added up to more than the limit for filename length.
Also make sure the programs you want to use can properly understand the file names you use.
My example is that Windows will happily accept fancy Unicode characters into filenames (e.g., Korean letters), but many programs will not accept those filenames as legitimate (e.g., Paint Shop Pro), much to my frustration (renaming 1000 photo files can be a chore).
Apple’s older HFS file system has a 31 (not 32) character limit on filenames. The OP indicates he might be transferring files from NT to a Mac, and perhaps this is where the error message is coming from.
Actually, the OP says “us Macs using an NT Server”, which suggests that he is a Mac. Strange. Being a computer, where did he come up with his SDMB registration fee?
As long as this topic doesn’t seem to be dying, I will also modify my “avoid the period” to add “unless what follows it is a legitimate extension for the type of file”, and suggest that if there is a recognized extension for the file type it SHOULD be there. What I was getting at is not naming the damned thing something like “This is Fred’s data. So there!”.
In my experiments I was (somehow) able to copy over files to the NT server with the characters you cited (except for the colon which Macs can’t use). Did they get corrupted or become unreadable in the process?
If you consider that this server only being used to hold Mac files used by Mac systems, I think that manipulating files with scripts isn’t an issue (or am I wrong?). I also don’t know when I would ever use their filename in a URL. And can you explain what “escaping issues all over the place” means?
Hi Nanoda I appreciate your help. Does DOS figure into this? As I mentioned above, this is used exclusively for Mac file accessed by Mac computers. We deal with a lot of image files for our clients, and there really is the need to use a descriptive file name rather than the heavily abbreviated DOS filename (8 chars + the filename extension, right?).
In any case, I’m sure we would never use a name with ONLY the letters NUL or CON, but would it also cause a problem if the letters “nul” or “con” were elsewhere in the filename like “Conservation Anullment.eps”?
Thanks again for giving this Mac user your insight into the world of Windows.
Yeah, the 31-char limit surprised me too. I know that was a limitation with Mac OS 9, but I always knew Windows to be able to handle more characters. In any case, when I copy over to the NT Server, it doesn’t take it unless it’s 31 or less.
Can you explain how “Unicode path names” figure in to filenames. That degree of technical background is a bit beyond this graphic design.
Right, not a problem. The files will be created with the programs that need to use them: typically the Adobe suite, Flash, and the occasional QuarkXPress file thrown in once in a great while.
I agree. I am all about using standard filename extensions. One question I have, though is that every once in a while, I’ll get a document from a PC user upstairs via e-mail and they actually will have additional dots in the filename before the filename extension. Is this not a problem? What dangers are prone to happening to these files?
Likely they got translated. I’m writing from a win2k box with an NTFS filesystem, and just confirmed that that set is the error message you get if you attempt to name a file “?”, for instance. Look on your NT server and see how they are actually presented in the filesystem explorer. If you somehow DID create a file with “/” in it, it would create major problems trying to refer to it since “/” or “” are the file path delimeters - if you named a file “a/b”, and also had a directory named “a” at the same level containing a file named “b” there’s obvious problems distinguishing between the two files.
Escaping (and quoting): I’m just referring to the fact that if your filename turns up in another context, like a URL or is manipulated by a script, a punctuation mark is likely to mean something special, so you have to take care to use whatever is the appropriate mechanism in that context to say you LITERALLY want the punctuation mark. That is usually generically called “escaping”. For instance, if your file contained a +, and you wished to refer to it through a URL, + is normally syntax to embed a space in the URL. You would have to use %2B in the URL instead of the +. If you have spaces in your file names, every non-quote protected reference in a shell script is going to throw up.
With a mac there are several ways to mount to a CIFS (aka SMB aka Windows file share) and you should consider possibly using a “by hand config”.
Many of the files that you are going to want to transfer will store the “special” names in an extra “hidden file” with a . prefix. Please note that system 10 converted to a BSD varient which pretty much follows those same “standard” conventions, but uses the . files to “translate” things.
Now I agree with the other posters that you should really follow “standard” naming conventions, but there might be something else that you could try.
Open a terminal window
cd /mnt (it should just bring you back to the prompt)
mkdir TEMP (again it should bring you back to the prompt)
For the next command:
IP=IP address of the Windows server
User=A valid user on that Windows server or the domain
SHARE NAME=The volume or share that you are trying to mount, typically this the directory name
mount_smbfs -I <IP> //<USER@IP>/<SHARE NAME/> /mnt/TEMP
This hopefully comes back to a prompt. Now if you look in finder that volume should be “viewable” as Mac does recognize it, however it now more easily supports unix like commands.
So now try something like "cp /Users/<your name>/<dir of crud>/* /mnt/TEMP/
This will not mean that Windows users can view your files, but I think you and other Mac users might be able to.
If this doesn’t work, might I recommend that you use a Linux client running samba which can usually talk to everyone pretty nicely.
Please note the advice is free, and most likely not worth what you paid. :rolleyes:
If the files are on an NT box, then DOS will figure in to things. (It’s there under all the nifty looking stuff in most Microsoft OSs) I just tried to create a file ‘CON’ on my 2k box, and got the error message “Cannot create or replace file: The filename you specified is invalid or too long.” If the file is being stored on an NT server, then at some point it’ll have to take a look at it, and won’t like that.
The only reason I’d stick to 8.3 filenames these days is if I was dealing with some embedded DOS device, or was running a particularly old application built for Win 3.1 Go nuts.
Microsoft may be able to screw some things up and get away with it, but something like that would be pushing it.
Sure. Now I’m all curious about special Mac filenames you’re not allowed to mess up.