Mac and Windows OS File/Folder naming rules
The following list is fairly exhaustive and pulls together references from various sources. Although not mentioned explicitly, Unix seems to have few - if any - restrictions. Compliance with these conventions as assets are added to your library will allow widest use of the assets without subsequent manual intervention to re-path/name, etc. The rules take into account the use of assets on local & network hard drives, CD/DVD, removable drives and online (web/ftp) using Mac OS9/OSX and Windows OSs:
- Illegal filename characters, (e.g. : or ?). (All OSs).
- Deprecated filename characters (; and ,). (All OSs).
- >31 filename characters including extension. (Mac Classic).
- >64 filename characters including extension. (Windows: ISO9660+Joliet CD or Hybrid CD partition).
- No extension - extensions are mandatory for Windows and the only means for Portfolio to tell file type. (Windows, Mac OS X).
- Filename has >1 period - Portfolio may misinterpret extension. (Windows, Mac OS X).
- Extension may be wrong, i.e. not 3 characters. (Windows, Mac OS X).
- Illegal characters in path to file - same issue as #1 but for path. (All OSs).
- Deprecated characters in path to file - same issue as #2 but for path. (All OSs).
- Filename may not begin with a period. (Windows not allowed, Mac treats as a hidden file)
- Filename may not end in a period. (Windows not allowed - OS 'throws away' the trailing period when naming/reading so incorrect matching vs. Mac name)
- Names conflicting with some of Win OS' old DOS functions (Not allowed in either upper or lowercase and with or without a file extension or as a file extension: COM1 to COM9 inclusive, LPT1 to LPT9 inclusive, CON, PRN, AUX, CLOCK$ and NUL)
- Case sensitivity. Windows OSs (and IIS web servers) aren't case sensitive. Most other OSs (and web servers) are.
- Filenames ought not to begin with a hyphen (Unix systems my interpret the filename as a flag to a command line call).
Notes:
- Whilst the illegal characters are simply not supported for use by one or more of the OSs to be used, the deprecated characters include those deprecated for naming purposes plus those likely to cause use in a web/ftp environment.
- #1. Illegal filename characters: \ (backslash), / (forward slash), : (colon), * (asterisk), ? (question mark), " (double quotes), < (left angle bracket), > (right angle bracket), | (pipe). Most of these are Windows OS constraints; Mac allows all except a colon (though a forward slash, /, can cause issues for POSIX paths). The aim here is to allow problem-free cross-platform use. An all-Windows or all-Mac organisation may need to interact with others using different OSs, so the safe method is to observe both OS' limitations, even if you mostly/always work on only one OS.
- #2. Avoid %, #, and $ as these are commonly used as variable name prefixes, so it can get messy if automating anything with filenames that include these characters. If networking cross platform (e.g. Samba, SMB, CIFS) consider effects of !+{}&[] on path and filename translation.
- #2. Where possible avoid spaces in filenames (though not strictly necessary, they can complicate things, especially if scripting). You are best advised to stick to alphanumerics, underscores, hyphens, periods. Do not use a hyphen or a period as the first or last character of a filename as this can have special meaning on some OSs (e.g. a starting period often indicates the file is hidden or system file that is not displayed to non-admin user accounts).
- #2. File/folder delimiters: Mac Classic uses a colon, Mac OS X uses either forward slash (POSIX paths) or colon ('Mac' paths), Unix uses a forward slash and Windows a backslash (plus colon for drive letter).
- #2 & #9. Deprecated filename & path characters: , (comma), ; (semi-colon), (space), • (bullet = ASCII #149), % (percent), & (ampersand). The 'bullet' character has no special significance but does seem popular as a form of name punctuator amongst some Mac users but it can cause unreadable filenames in a cross-platform environment.
- #2 & #9. Unix has few limitations. Filenames may be up to 256 characters. A forward slash (/) is a folder delimiter and a leading period (.) makes that file a system file.
- #3 & #4. Windows, Unix and Mac OS X all support long filenames. References conflict as to whether exactly 256 or 255 characters are allowed (in Windows this includes the extension). However, as no current OS will allow you to create a filename exceeding this and all have the same top limit, this is one constraint you are unlikely to have to test for!
- #3. Consider the impact of long filenames on their display in OS and program dialogs, web pages etc. For instance Firefox won't wrap long strings of alphanumeric characters (nor can you force it to do so via code) so that long filenames may 'break' web layouts not designed with this issue in mind.
- #4. The 'Joliet' standard for Windows CD supporting long filenames has a limit of 64 characters for the total path (folders & filename). If you need deep nesting, use short folder and file names! Also watch for limitations on the depth of folder nesting that can occur with strict observance of ISO9660 (see first bullet in next list). This is something that is rarely explained in CD/DVD burning software and is more likely to bite when using older systems/software. If path length limitations are a likely issue then make sure you test before starting any large body of work.
- #5. Whilst modern 32-bit Windows (post Win 95) is will tolerate files without extensions it does not know how to handle them. In addition some apps use the OSs 'knowledge' of file types to help it when finding/opening files - i.e. if the OSs is confused so to will be some apps. Bottom line, if Windows use is likely always have file extensions. OSX usage seems to be drifting towards the extension model now resource fork info is becoming a legacy issue.
- #6. Mac, making less deliberate use of extensions allows periods in names. Portfolio will assume the set of characters after the right-most period in the name is the Windows-compatible extension. So if you must have, for example, "myname.txt.stuff" for a text file, better to call it "myname.stuff.txt"; Portfolio will read the first as having extension ".stuff", whilst the second will be read as ".txt".
- #6. If you intend to transmit files over the internet (especially as an email attachment) multiple periods such as "filename.tif.zip" will often get the file killed in transit. This is because IT systems that see files with "multiple extensions" as a risk since the true nature of the file may be "masked" so that a worm/virus can inflict damage. See also the notes on #9 below - more than one period in a path (whether folder or filename) may be intepreted by a well-secured web server as an illegal path (possible hacking attempt) and the file at the path won't be served.
- #7. Windows convention is for three letter extensions but more or fewer characters are not unknown, e.g. "logo.ai" (Illustrator) "page.html" (some HTML editors' output). The point of this rule is not to insist extensions of 3 characters but to flag up odd - normally Mac created names - that might have problems on Windows computers.
- #8. Illegal path characters: as above minus backslash and colon.
- #9. Periods, though allowed in filenames, are deprecated as they aren't supported in stricter ISO9660 versions (without Joliet) and on some older systems such as VMS.
- #9. For web use, periods in filenames are deprecated as some web servers (especially IIS), when fully security patched, will not serve content if the URL has any folder names containing a period (effectively the underlying server 'rule' being applied is to check the path for > one period, assuming the filename at the end of the path contains a single period).
- #10/11. You are well advised not to use commas as a starting or finishing character - they are likely to get missed when reading by eye.
- #12. See also MSDN. "Null.txt" is allowed but "nul.txt", "NUL" or "nul" are not.
- #13. Consider being case-insensitive when naming. In a large archive it can be tempting fate to rely on case to distinguish a file from another; thus ideally "Filename.jpg" and "FILENAME.JPG" should resolve to be the same file. In addition, "Filename.jpg" is arguably not unique. So regardless of whether your primary OS is case-sensitive, it is a good idea to (a) treat all case variations of a name as one for uniqueness of naming but (b) use only ever use one variant of the name (as if the OS were case-sensitive).
- #14. Unix system command line calls usually involve a program command with a series of hyphen-prefixed letter(s), or 'flags', that alter that program's behaviour. Starting a filename with a hyphen on such systems could cause the filename to be misinterpreted in command lines as a concatenated set of flags and thus not processed as a filename as intended.
So that's it then?
Not really, these rules are advisory - you will need to think how to apply them. For instance you may work only on Mac OS and thus don't need to worry about folder names but you will need to ensure you files - or those you may need to send to users not on Macs - have extensions. Of course, the extension needs to be appropriate - don't put '.jpg' on the end of a TIFF, for example. If you're unsure about extensions there are numerous online listing that will give these to you.
On the subject of extensions, this is one thing it's not too easy to change in Portfolio except via 'link to new file' or scripting. As 'link to new file' require you so manually set each connection, scripting is the way to go - if you can define the changes to make.
Anyway, don't feel compelled to apply all of the above rules. Rather, be aware of them and apply them as appropriate. If you are starting a new collection or re-ordering old content you're at the right point to get some discipline into the naming. If some or all of your new content comes in from external sources and is poorly named, sit down with your partners make sure good naming rules are in the contract. Then, if it's wrong, they can rename files at their time/expense - a good encouragement for them to adopt good practice from outset.
Some final thoughts
You might also consider these additional rules where older OS variants are in use:
- Strict ISO9660 Level 1. Files and folders max 8.3 characters; only uppercase letters, numeral, or underscore characters allowed. Folder may only nest 8 levels (i.e. 7 below the root) in the strictest interpretation of the standard. ISO level 2 extends filename length to 31 characters.
- 8.3 filenames. Files must be 8.3 characters or less (x.y through xxxxxxxx.yyy) and folders 8 or 8.3. characters or less (\x\ through \xxxxxxxx\ and \x.y\ through \xxxxxxxx.yyy\ - noting folder names with extensions are deprecated in Windows OS usage).
- Non alphanumeric characters (i.e. only allow letters and numbers).
- What 'special' characters does Windows (95/98) allow? The following is from Microsoft. Note that many of the following are deprecated for cross-platform workflow use for the reasons already stated above:
$ Dollar sign
% Percent sign
' Apostrophe
` Opening single quotation mark
- Hyphen
@ At sign
{ Left brace
} Right brace
~ Tilde
! Exclamation point
# Number sign
( Opening parenthesis
) Closing parenthesis
& Ampersand
_ Underscore
^ Caret
+ Plus sign
, Comma
. Period
= Equal sign
[ Opening bracket
] Closing bracket
Other Useful Links (Open in new window)
ControlledVocabulary.com - Filenaming
Wikipedia - File Name
Wikipedia - ISO9660
Question: Mac and Windows OS File/Folder naming rules [FAQ00352.htm]
Last Update:- 04 September 2007
