Exact nomenclature for filenames and paths, especially in Win XP

umask should make it possible.

How do (or did) one do this in Unix? I’m familiar with a file being in a single, static directory, and then symlinking the file in other directories, but I’m not at all familiar with what you describe, which sounds like the old Mac FFS (flat file system) where directories were illusions, but then the file only appeared once in its directory rather than in multiple directories.

Nope. ‘umask’ with the ‘x’ bits turned on will only set the execute permissions on directories, not files — and, “execute” for a directory is not actually about program execution, confusingly.

What I think Napier is talking about are hard links (as opposed to symbolic links), where the exact same file can appear in multiple directories, possibly under different names. In fact, every regular file has at least one hard link anyway, even if you’re unaware of it.

Deleting a file from a directory therefore doesn’t delete the file from the disk, in the case where there are 2 or more hard links to the content. It merely means the file no longer appears in that one directory. When the number of hard links falls to zero, that’s when its disk space is freed up and the file is gone. More or less.

Hard links are created through the same command symbolic links are — the ‘ln’ command. You simply omit the ‘-s’ option.

>How do (or did) one do this in Unix?
>What I think Napier is talking about are hard links (as opposed to symbolic links), where the exact same file can appear in multiple directories, possibly under different names. In fact, every regular file has at least one hard link anyway, even if you’re unaware of it.

Bytegeist is exactly right. I mean the hard links.

Realize that a file isn’t really in ANY directory OR folder, in the sense of being contained somehow. Files are scattered all over the damn drive. They aren’t even in single places. Many of them are scattered in various fragments. There is an elaborate system for keeping track of them all that lets you find them, read them, add to them, and so forth. There is the File Allocation Table of DOS, the High Sierra File System (hsfs), and god knows how many other.

The basic method in Unix, at least when I was using BSD and SVR4, was that creating and filling a file required that you also list it in at least one directory. From the user’s point of view, you have to give the file a name and put it someplace. From the system’s point of view, you have to associate the file with a brief character string or a string of character strings (a name of a path consisting of directory names and a filename). You can associate the file with as many of these as you like, which is called creating links to the file. They are all equally important ways of telling the system, in terms you grasp, which file you are referring to.

If you get rid of the last link, you are getting rid of the last way you have of identifying the file to the system. From the system’s point of view, if you no longer have a way of pointing at the file, it isn’t useful anymore and the space it’s written on is marked as available (though the file’s data remains in that space until something else intrudes on it).

I went crazy when installing a program which did not understand “C:\program files” and “C:\progra~1” where the same directory. Beware of that.

I’m not going to get into all the variations of file designators. Your question is not about software, it’s about terminology and technical writing.

And I’m a technical writer!:smiley:

Microsoft has standard terminology for every part of their software. Most of it is in the Microsoft Manual of Style, which unfortunately I don’t have at hand (it’s in my office, and I’m at home). Still, you should try to find a link to it on the Microsoft web site. I would be surprised if it were not there.

Other, more general technologies such as HTTP, XML, and so forth, have their own terminology that may be more useful for entities such as URIs.

Unfortunately, this still leaves you to be the person to choose what to use. Consider your audience; what terminology will they recognize without further explanation? Use that wherever you can.

If you have any doubts about what they’ll recognize, then provide a glossary. All the Windows help systems I know allow you to link glossary entries to words in the text.

On the other hand, you may just decide to bag all this. The upside is you save time and worry. The downsides are that your users pester you with questions and use the software incorrectly. Perhaps, given your expectations of your users, this won’t be much of a problem. In other words, I imagine that an experienced Mac user would be able to find a file in Windows Explorer even without help.

Unsolicited polemic in favor of technical writing: You now see why having goodtechnical writers is important. If I had a nickel for every time I’ve heard an engineer say “We don’t need a technical writer; I know how to write!”, well, I’d be retired already.

Of course, bad technical writing is as terrible as bad software writing.:smack:

633squadron, thank you. I sense we are kindred souls.

I did not know of the Microsoft Manual of Style, and will go hunt it down. It would please me greatly if I could be consistent with such a document and be clear. Moreover, I would like to see if I can figure out the multiple personality disorder that Microsoft seems to promote for PC users. Why is it “My Computer” if it is asking “Where do you want to go today?” of “username”?

I think that the things that are done in computers without the benefit of good technical writing constitute the largest body of ugliness in the field. I even think that most of the features in computer products are not used, and primarily for this reason. In my mind, products that integrate excellent documents, like the old HP calculators, or like the SAS System, are the best products, either specifically because of their documentation or because the mindset that produces the best products also naturally produces excellent documents.

I also like to write, and I try to do so clearly. Whether I do it or not is for others to judge, but I am certainly going to try.

The Microsoft Manual of Style for Technical Publications, 3rd Edition, is available for download at:

http://faculty.washington.edu/farkas/TC407/MSTP-V3.pdf

and is available as hardcopy for $19.79 at Amazon.com, where readers have given it a four star rating out of five. It’s 432 pages.