Val Abbott wonders why mv doesn't change a file's owner or permissions. It's because no new file is being created. Tomas Jensen needs to get rid of characters with the code 196 for a text file. I show how to accomplish this task with tr. Roger Corron takes issue with some statements I made when describing the mailcrypt command. I respond to his comments. Andy Levinson submits an 18-line C program that reports a file's permissions in octal values. Stephen Potter supplies a Perl script that finds all the subdirectories in the current directory.

On the Move

Question: Why is it that copying a file with cp creates a file with a new owner but moving a file with mv leaves the new file with the original owner?

Answer: It is clear that copying a file must make a new file on the system, which is the copy requested. Whenever a new file is created on the Unix system, its owner is assigned to be the user who is running the program that created the file. In addition, the new file is given its own set of permissions that may or may not match the original.

The reason why moving a file leaves the moved file with the same owner is because you haven't created a new file. You've simply given an existing file a new name.

Let me explain this event a bit further. On the Unix system, a file is represented by two parts: an inode and a link.

The inode represents all the information about the file including who owns it, its permissions, and the data blocks holding the file's text, among other details. The two things not identified by a file's inode are its name and the directory that holds that name. This information is specified in a link.

Inodes are numbered. To make them easier for humans to identify, files are given names by associating a name with an inode number. A file name is linked to a directory by placing the inode and file-name pair in a directory file. Thus a link is the file name that points to the inode.

The mv command simply discards the existing link and creates a new one, leaving the file's inode and all its information untouched. Because the inode is unchanged, so is the file's owner and permissions.

It is worth noting that while the mv command leaves the newly named file unchanged, it does change the directories containing the links, which means that the directory holding the original link is modified by the removal of that link name as is the destination directory by the addition of the new link name. Thus, both directories will have their modification and change times updated.

[Editor's note: A request to move a file from one file system to another is serviced by a copy operation because links are unique to a file system.]

Octals at 8

Question: After getting and converting a file from another system, I noticed some funny characters interspersed in the text. I discovered that the character was represented by the code 196. How can I get rid of these characters without having to go through the text by hand to find them?

Answer: The easiest way to delete a single character from text is to use the tr command. Without options, tr converts one character to another. It also will delete characters, if you use the -d option followed by the character to delete.

Unfortunately, tr is a bit odd, even for a Unix command. It only reads characters from its standard input and only writes to its standard output. Thus, unless used in a pipeline, you must redirect tr's standard input to come from the disk file.

In addition, tr doesn't understand decimal values. You must send it ASCII characters (decimal value below 128) or octal values. To delete all the code-196 characters in the file, you must first convert 196 to its octal equivalent. Listing 1 shows the dec2oct script, which takes decimal numbers as input and prints out their octal values. Entering 196 into the dec2oct command told me that 196 is 304 in octal.

The Unix convention is that octal values are identified by prefixing a backslash to the octal number. Thus, octal 304 is represented by \304. The tr command line is:

tr -d '\304' < input_file > output_file

Note:The single quotes around the \304 are required.

mailcrypt Gripe

Feedback: Although I have previously found ``Answers to Unix'' to be accurate and useful, I was surprised and disappointed by your reply in the June 1994 column to the questioner seeking mail privacy. There is no way to maintain the privacy of system mailboxes when others have root access to the system. The problem is that root users have universal access to the entire mail configuration and to the entire file system.

The brute force way of defeating mailcrypt is to disassemble the executable and read the code. Most Unix development environments have disassemblers, either as part of the debugger or as standalone tools.

The easy way to defeat mailcrypt is to modify the system Sendmail configuration to save duplicate copies of the mail before it is even delivered to mailcrypt. That could be done either by changing the configuration (in sendmail.cf) or more simply with the system alias file (generally /etc/aliases). This setup is possible on the destination system or on any forwarding host along the way.

The only way to maintain privacy of electronic mail is to ensure that the source and destination systems are trustworthy and that the e-mail is encrypted before it is sent. Contrary to your assertion that ``the obvious problem with PEM is that everyone has to use it,'' only the sender and receiver need use it. (Anyone who cannot convince their correspondents to stop e-mailing embarrassing information in the clear has bigger problems than nosy system administrators.)

Your correspondent would be better served by a home computer with a private Internet or UUCP connection. He could use PGP (Pretty Good Privacy) if he thinks he needs more privacy. The Electronic Frontiers Foundation has recently started distributing PGP for noncommercial use.

Response: You say that my answer in June 1994 using mailcrypt is insecure. I don't quite agree. The reader who asked the question didn't describe the situation in enough detail to identify how the embarrassing e-mail came to the attention of the system administrator. If it was by some foolish mistake on the reader's part, then it may be possible to ``hide'' e-mail using mailcrypt.

On the other hand, if the administrator discovered the e-mail by snooping on the system's users, your point of view is more appropriate. In my experience, administrators usually have more to do than spend their time disassembling encryption programs.

If you further assume that the system administrator is out to get you, can reconfigure system software at will, and doesn't mind obvious issues related to privacy, then I suggest that even using PGP won't help. Ultimately, what an administrator can do to Sendmail (make it copy all incoming mail), an administrator can do to the serial device driver (so that it copies your keystrokes and identifies your private key if PEM or PGP is being used).

The bottom line is, as you say, that the reader would be safer with a private Internet connection. But then, what about the Internet provider?

Here is how I began my answer in the June issue:

Let me be very clear. Electronic mail is not private. People can (and will) read it.

I still believe these sentences say it all.

Getting Permission Faster

Feedback: In your July 1994 column, you published an 18-line script by Daniel E. Singer that uses cpio to show file permissions in octal. There are two problems with the script. First, it is overkill and slow because cpio must shuffle about data that is thrown away anyway. Second, the script does not work as intended under System V Release 4.2, which is true to the manual. The cpio -itv command indeed looks like an ls -l command, showing file permissions in familiar symbolic (``rwx'') format.

I've written a simple 18-line C program (Listing 2) that is the same length as Mr. Singer's shell script but is immensely faster and works on any Unix system. Indeed, it even works under DOS to the limited extent that DOS supports file permissions.

Feedback: This little Perl program (Listing 3) will list only the directories in current directories.