This guide is an introduction to the file naming conventions you will see used when using ssTek. As the already well-established release groups had long ago discovered, a filename can contain a ton of info. So it's important how we structure or format our database-like filenames.
Indexing Structures, Filing Systems, and Character Sets:
With any large amount of information, it is important for the people accessing it to have some kind of structure to navigate their way to the information they're looking for. If there is no structure for locating specific data, the collection of information is virtually useless and the task of finding what you are looking for becomes like trying to find a needle in a haystack.
For this reason, a relatively new convention was developed for the naming of files. This naming convention was formally ratified by many - if not most - of the well known release groups. The use of these standards, along with the files they are attached to, have trickled down to the P2P community, and now to us here at ssTek.
Rules for naming files and folders are an important part of the standards. Correctly named folders make it easier to maintain clean archives and unique filenames are necessary to allow any duplicate checker program to work properly.
Also, since FTP servers, operating systems, or file systems may not allow special characters in file or directory names, only a small set of characters is allowed. And substitutions are made where special characters would normally be used (e.g. ç replaced by c); or these characters are simply omitted, such as an asterisk(*).
So in order to minimize the problems due to the many platforms a release may encounter during its distribution, a very specifically defined character set is used in naming of the files and folders. This ubiquitous character set includes the upper- and lower-case English alphabet, numerals, and several basic punctuation marks. It is outlined below:
- [font=Courier New]ABCDEFGHIJKLMNOPQRSTUVWXYZ
Since spaces are explicitly disallowed in all current standards, the first thing you'll see is a lot of dots; or full stops if you insist on using the 20th century term for them. Get used to it and learn to love 'em.
The reason you see dots instead of spaces (Kind.Of.Like.This) is because different operating systems and software read spaces in different ways. For example, even in simple HTML, a space can often be automatically converted to %20, depending on why kind of software you're using to read it and how well that software converts the encoded text into human-readable text.
Rather than making people decipher file%20names%20like%20this%20which%20are%20hard%20to%20read, the dots make file.names.like.this.much.easier.to.read.
Spaces in file names can also cause broken links, because word processing tools like Microsoft Word, and e-mail clients like Microsoft Outlook, recognize spaces as an opportunity to move to another line. Therefore, a link to
- \\Ah1\Intranet\ar\naming conventions
And finally many scripts/batch/cmd files would require filenames with spaces to be enclosed in double-quotes otherwise the spaces are interpreted as parameter breaks much like what the word processing tools would do to them.
First the syntax. (NOTE: The following should be considered all one file or folder name):
- [font=Courier New][<Developer>.]<Title>_v<Version>|c<Year>[_<Language>][_<OS>][_<Architecture>]
- Anything inside brackets "" is optional
- Do not actually enter the "<>" characters
- "|" represent choices
- NO spaces.
- Substitute dots(.) for spaces inside <field>s.
- Use underscores(_) as separators between <field>s.
- NO double-dots nor double-underscores.
- <Developer> is only really mandatory if the application name is not unique enough that duplicates are not likely to exist. This means that you must include the developer in the case where checks for duplicates for your application name will also return results that do not match the application you are releasing. Including the developer would also be appropriate if the developer's releases are typically listed together, those from Adobe or Microsoft for example.
- <Title> must be the "official" name of the application. Do not omit dashes, think of your duplicate checking results. This is the name in the about box or splashscreen of the application, or if this is not available, the name listed on the website.
- _v<Version> should be used for applications, and _c<Year> should be used for games. Dashes are also appropriate here. E.g, "-Beta"
- The <Language> tag must be used only on NON English releases. Multilingual and bilingual are optional.
- It is recommended to omit the <OS> tag when it is "All Windows" (= NT5 & NT6 based windows, always with latest official service pack). Currently valid OS tags are:
- NT5 [2K/XP/2K3]
- NT6 [Vista/7]
- It is recommended to omit the <Architecture> tag when it is x86 and it works perfectly okay on an x64 system or if separate installers are included for the two different architectures but only one will get installed depending on the target system. Currently valid Architecture tags are:
- x86 [will ONLY run correctly on x86 systems]
- x64 [will ONLY run on x64 systems]
- DualArch [will run on either x86 or x64 systems... this ONLY works with ppApps or ppGames exclusively]
- <BuildType> is the type of deployment package/build. Possible tags are:
- Releasers should use some common sense to keep the filename a reasonable length.
Finally, to help illustrate some of the rules, we present a few examples of properly formatted filenames should look like:
- [font=Courier New]7-Zip_v9.25Beta_x64_ssApp_bphlpt.apz