QNX Developer Support
|This version of this document is no longer maintained. For the latest documentation, see http://www.qnx.com/developers/docs.|
This chapter includes:
- Everything is a file
- Filenames and pathnames
- Where everything is stored
- File ownership and permissions
- Filename extensions
|This chapter concentrates on working with files in the QNX 4 filesystem, which is the default under Neutrino and is compatible with the older QNX 4 OS. For more information, see the Working with Filesystems chapter in this guide.|
In a Neutrino system, almost everything is a file; devices, data, and even services are all typically represented as files. This lets you work with local and remote resources easily from the command line, or through any program that works with files.
Neutrino supports the following types of files, and ls -l uses the character shown in parentheses to identify the type:
- Regular (-)
- A file that contains user data, such as C code, HTML, and data. For example, /home/fred/myprog.c.
- Directory (d)
- Conceptually, a directory is something that contains files and other
For example, /home/fred.
A directory is implemented as a disk file that stores a list of the names of files and other directories. Each filename is associated with an inode (information node) that defines the file's existence. For more information, see "QNX 4 filesystem" in Working with Filesystems.
- Symbolic link (l)
- An additional name for a file or directory. For example, /usr/bin/more is a symbolic link to /usr/bin/less. For more information, see "Symbolic links" in Working with Filesystems.
- Named special (n)
- A shared memory region, such as, /dev/shmem/Pg101e0001.
- Character special files (c)
- Entries that represent a character device. For example, /dev/ser1 represents a serial port.
- FIFO special files (p)
- Persistent named pipes through which two programs communicate. For example, PipeA
- Block special files (b)
- Entries that represent a block device, such as a disk. For example, /dev/hd0 represents the raw block data of your primary disk drive.
- Socket files (s)
- Entries that represent a communications socket, especially a UNIX-domain socket. For more information, see socket() and the UNIX protocol in the Neutrino Library Reference.
Some files are persistent across system reboots, such as most files in a disk filesystem. Other files may exist only as long as the program responsible for them is running. Examples of these include shared memory objects, objects in the /proc filesystem, and temporary files on disk that are still being accessed even though the links to the files (their filenames) have been removed.
To access any file or directory, you must specify a pathname, a symbolic name that tells a program where to find a file within the directory hierarchy based at root (/).
A typical Neutrino pathname looks like this:
In this example, .profile is found in the fred directory, which in turn resides in the home directory, which is found in /, the root directory:
Like Linux and other UNIX-like operating systems, Neutrino pathname components are separated by a forward slash (/). This is unlike Microsoft operating systems, which use a backslash (\).
|To explore the files and directories on your system, use the ls utility. This is the equivalent of dir in MS-DOS. For more information, see "Basic commands" in Using the Command Line, or ls in the Utilities Reference.|
There are two types of pathname:
- Absolute paths
- Pathnames that begin with a slash specify locations that are relative to the root of the pathname space (/). For example, /usr/lib/libmalloc.so.2.
- Relative paths
- Pathnames that don't begin with / specify
locations relative to your current working directory.
For example, if your current directory is /home/fred, a relative path of .ph/helpviewer is the same as an absolute path of /home/fred/.ph/helpviewer.
The pathname, /home/fred/.ph/helpviewer, actually specifies a directory, not a regular file. You can't tell by looking at a pathname whether the path points to a regular file, a directory, a symbolic link, or some other file type. To determine the type of a file, use file or ls -ld.
The one exception to this is a pathname that ends with /, which always indicates a directory. If you use the -F option to ls, the utility displays a slash at the end of a directory name.
Every directory in a QNX 4 filesystem contains these special links:
- . ("dot")
- The current directory.
- .. ("dot dot")
- The directory that this directory appears in.
So, for example, you could list the contents of the directory above your current working directory by typing:
If your current directory is /home/fred/.ph/helpviewer, you could list the contents of the root directory by typing:
but the absolute path (/) is much shorter, and you don't have to figure out how many "dot dots" you need.
|Flash filesystems don't support . and .. entries, but the shell might resolve them before passing the path to the filesystem. You can also set up hard links with these names on a flash filesystem.|
In some traditional UNIX systems, the cd (change directory) command modifies the pathname given to it if that pathname contains symbolic links. As a result, the pathname of the new current working directory -- which you can display with pwd -- may differ from the one given to cd.
In Neutrino, however, cd doesn't modify the pathname -- aside from collapsing .. references. For example:
would result in a current working directory of /home/dan/doc, even if some of the elements in the pathname were symbolic links.
Unlike Microsoft Windows, which represents drives as letters that precede pathnames (e.g. C:\), Neutrino represents disk drives as regular directories within the pathname space. Directories that access another filesystem, such as one on a second hard disk partition, are called mountpoints.
Usually the primary disk-based filesystem is mounted at / (the root of the pathname space). A full Neutrino installation (such as a self-hosted QNX Momentics development installation) mounts all additional disk filesystems automatically under the /fs directory. For example:
So, while in a DOS-based system a second partition on your hard drive might be accessed as D:\, in a Neutrino system you might access the second QNX 4 filesystem partition on the first hard drive as /fs/hd0-qnx4-2.
For more information on where to find things in a typical Neutrino pathname space, see "Where everything is stored," later in this chapter. To learn more about mounting filesystems, see Working with Filesystems and Controlling How Neutrino Starts.
When you list the contents of a directory, the ls utility usually hides files and directories whose names begin with a period. Programs precede configuration files and directories with a period to hide them from view. The files (not surprisingly) are called hidden files.
Other than the special treatment by ls and some other programs (such as the Photon file manager, pfm), nothing else is special about hidden files. Use ls -a to list all files, including any hidden ones.
Filename extensions (.something at the end of a filename) tell programs and users what type of data a file contains. In the QNX 4 filesystem (the Neutrino native hard disk filesystem), extensions are just an ordinary part of the filename and can be any length, as long as the total filename size stays within the 505 byte filename length limit.
Most of the time, file extensions are simply naming conventions, but some utilities base their behavior on the extension. See "Filename extensions" later in this chapter for a list of some of the common extensions used in a Neutrino system.
You may have noticed that we've talked about files and directories "appearing in" their parent directories, rather than just saying that the parent directories contain these files. This is because in Neutrino, the pathname space is virtual, dictated not just by the filesystem that resides on media mounted at root, but rather by the paths and pathname aliases registered by the process manager.
For example, let's take a small portion of the pathname space:
In a typical disk-based Neutrino system, the directory / maps to the root of a filesystem on a physical hard drive partition. This filesystem on disk doesn't actually contain a /dev directory, which exists virtually, adopted via the process manager. In turn, the filename ser1 doesn't exist on a disk filesystem either; it has been adopted by the serial port driver.
This capability allows virtual directory unions to be created. This happens when multiple resource managers adopt files that lie in a common directory within the pathname space.
|In the interests of creating a maintainable system, we suggest that you create directory unions as rarely as possible.|
For more information on pathname-space management, see "Pathname Management" in the Process Manager chapter of the System Architecture guide.
Neutrino supports a variety of filesystems, each of which has different capabilities and rules for valid filenames. For information about filesystem capabilities, see Working with Filesystems; for filesystem limits, see Understanding System Limits.
The QNX 4 filesystem is the normal hard-disk filesystem that Neutrino uses. In this filesystem, filenames can be up to 48 bytes long, but you can extend them to 505 bytes (see "Filenames" in Working with Filesystems). Individual bytes within the filename may have any value except the following (all values are in hexadecimal):
- 0x00 through 0x1F (all control characters)
- 0x2F (/)
- 0x7F (rubout)
If you're using UTF-8 representations of Unicode characters to represent international characters, the limit on the filename length will be lower, depending on your use of characters in the extended range. For more information on UTF-8 and Unicode, see the Unicode Multilingual Support appendix in the Photon Programmer's Guide.
You can use international characters in filenames by using the UTF-8 encoding of Unicode characters. If you're using the Photon microGUI, this is done transparently (you can enter the necessary characters directly from your keyboard, and the display shows them correctly within the Photon file manager). Filenames containing UTF-8 characters are generally illegible when viewed from the command line.
You can also use the ISO-Latin1 supplemental and PC character sets for international characters; however, the appearance of these 8-bit characters depends on the display settings of your terminal, and might not appear as you expect from within Photon or in other operating systems that access the files via a network.
Most other operating systems, including Microsoft Windows, support UTF-8/Unicode characters, and their filenames appear correctly in the Photon microGUI environment. Filenames from older versions of Microsoft Windows may be encoded using 8-bit characters with various language codepage in effect. The DOS filesystem in Neutrino can translate these filenames to UTF-8 representations, but you need to tell the filesystem which codepage to use via a command-line option. For more information see fs-dos.so in the Utilities Reference.
The default Neutrino filesystem generally follows the Filesystem Hierarchy Standard, but we don't claim to be compliant or compatible with it. This standard describes where files and directories should or must be placed in UNIX-style operating systems. For more information, see http://www.pathname.com/fhs.
|The Neutrino pathname space is extremely flexible. Your system may be configured differently.|
This section describes the contents of these directories (select a directory from this diagram to go to its description):
The / directory is the root of the pathname space. Usually your primary hard disk or flash filesystem is mounted here. On a QNX 4 filesystem, this directory includes the following files:
- Contains an alternate OS image that's loaded if you press ESC during bootup; see Controlling How Neutrino Starts.
- A system file that contains a bitmap representing the disk regions in use
by the filesystem.
Each block is represented by one bit; if the bit is set, the filesystem is
using the block.
You must preserve the integrity of this file to prevent disk corruption. After an unexpected shutdown, run chkfsys to walk through the entire filesystem and validate this file's contents, correcting them if necessary. For more information, see "QNX 4 filesystem" in Working with Filesystems, and chkfsys in the Utilities Reference.
- On a bootable filesystem, this file contains the primary OS image that's loaded by the secondary boot loader on bootup. For more information, see Controlling How Neutrino Starts, as well as "QNX Neutrino and QNX 4 bootloader partitions" in the Neutrino Technical Notes.
- A file that indicates which QNX 4 filesystem to mount as /. For more information, see Controlling How Neutrino Starts.
- Contains additional data pointing to extra inode blocks required by files that occupy more than one extent (i.e. more than one contiguous region on the disk device). For more information, see "QNX 4 filesystem" in Working with Filesystems.
The / directory also contains platform-specific directories (e.g. mipsle, ppcbe, x86), as well as the directories described in the sections that follow.
To display basic utility syntax, type use utilityname from the command line. For more information, see use in the Utilities Reference.
The /boot directory contains files and directories related to creating bootable OS images (image filesystems). Image filesystems contain OS components, your executables, and data files that need to be present and running immediately upon bootup. For general information on this topic, see Making an OS Image in the Building Embedded Systems guide, and mkifs in the Utilities Reference.
This directory includes:
- This directory contains the mkifs buildfiles used to build OS images. The buildfiles for a standard x86-based Neutrino system are qnxbase.build and qnxbasedma.build.
- By convention, we use this directory to store image filesystems built by mkifs. To boot from one of the images, you'll need to copy it to /.boot on a bootable QNX 4-filesystem device first.
- IPL and startup code are located here. This is one of the paths searched by the mkifs utility as it tries to resolve components named in the buildfile.
As described earlier, the /dev directory belongs to the process manager. This directory contains device files, possibly including:
- CD-ROM block devices; see devb-* in the Utilities Reference for driver information.
- Text mode console TTY device; see devc-con in the Utilities Reference.
- The device that's used for diagnostic log messages; on a full x86 system, this is a write-only device managed by the system logger, slogger. Buildfiles for embedded systems may configure a link from this path to another device, such as a serial port. See slogger in the Utilities Reference.
- Floppy disk block devices; see devb-fdc in the Utilities Reference for driver details.
- Hard disk block devices; data representing an entire drive, spanning all partitions; see devb-* in the Utilities Reference.
- Hard disk partition block devices; the data in these devices is a subset of that represented by the corresponding hdn file; see devb-* in the Utilities Reference.
- A directory owned and operated by io-net, under which you can find files relating to the network devices for your various LANs. C programs can perform devctl() operations on these files to interact with the driver, e.g. to obtain driver statistics.
- A device that represents all physical memory.
- /dev/mq, /dev/mqueue
- A pathname space where entries for message queues appear; for more information, see mq and mqueue in the Utilities Reference.
- A "bit bucket" that you can direct data to. The data is discarded.
- Parallel ports e.g. for parallel printers; see stty for configuration, and devc-par for driver details in the Utilities Reference.
- Adopted by the PCI server on the machine, this device lets programs communicate with the PCI server. See pci-* in the Utilities Reference.
- Adopted by the Photon font server, either io-graphics using the phfont.so library, or phfont running as a separate process. This file lets programs communicate with the font server. See io-graphics and phfont in the Utilities Reference.
- A special file that programs use to attach to a Photon server running on this machine. For more information, see Photon in the Utilities Reference.
- Adopted by the pipe manager. The presence of this file tells other programs (such as a startup script built into an OS image) that the Pipe manager is successfully running.
- /dev/ptypx, /dev/ptyqx, /dev/ptyrx
- The control side of a pseudo-terminal device pair. Pseudo-ttys are numbered with a hexadecimal digit. When more than 16 pseudo-ttys are present, devc-pty uses the additional prefixes, /dev/ptyq, /dev/ptyr, and so on, as necessary, to accommodate the additional ttys. See devc-pty in the Utilities Reference.
- Read from this device to obtain random data; see random in the Utilities Reference.
- A pathname space where entries for named semaphores appear.
- Serial ports. See stty for configuration, and devc-ser* for driver details in the Utilities Reference.
- Contains files representing shared memory regions on the system (also sometimes used for generic memory-mapped files). For more information, see the description of the RAM "filesystem" in Working with Filesystems.
- A device managed by slogger, used to read or write system log messages. Try sloginfo /dev/slog. See slogger and sloginfo in the Utilities Reference for more information.
- This directory is owned and managed through the TCP/IP stack (npm-tcpip.so or npm-ttcpip.so) running under io-net. This directory contains pathnames through which applications interact with the stack. For more information, see the TCP/IP Networking chapter in this guide.
- This file is managed by
Text written to this device is output through debug output routines
encoded in the startup code for your system.
The actual result, therefore, varies from board to board. On a standard PC (using startup-BIOS), the default is to write to the PC console. For more information, see startup-* in the Utilities Reference.
- A virtual device owned by the process manager (procnto) that resolves to the controlling terminal device associated with the session of any process that opens the file. This is useful for programs that may have closed their standard input, standard output, or standard error, and later wish to write to the terminal device.
- /dev/ttypx, /dev/ttyqx, /dev/ttyrx
- The slave side of the corresponding /dev/ptypx file. The program being controlled typically uses one of these files for its standard input, standard output, and standard error.
- Supplies an endless stream of bytes having a value of zero.
The /etc directory contains host-specific system files and programs used for administration and configuration, including:
- Specifies permitted operations on a defined SNMP context. See /etc/acl.conf in the Utilities Reference.
- Automatic TCP/IP connection-configuration script. See /etc/autoconnect in the Utilities Reference.
- Network boot protocol server configuration file. See /etc/bootptab in the Utilities Reference.
- A directory that contains system-configuration files, such as the ttys file that tinit uses to configure terminal devices.
- Context definitions for SNMP v2. See /etc/context.conf in the Utilities Reference.
- Set by phlocale, this is used by applications such as the software installer (qnxinstall) to tailor behavior for the country that you're running the system in.
- A directory that contains default configuration files, primarily for TCP/IP facilities.
- Dynamic Host Configuration Protocol configuration; see /etc/dhcpd.conf in the Utilities Reference.
- Specifies configuration options for ftpd that apply once you've authenticated your connection. See /etc/ftpd.conf in the Utilities Reference.
- Defines users who may access the machine via the File Transfer Protocol. See /etc/ftpusers in the Utilities Reference.
- User account group definitions; see Managing User Accounts.
- Network hostname lookup database; see also /etc/resolv.conf, below. See /etc/hosts in the Utilities Reference.
- Internet super-server configuration file that defines Internet services that inetd starts and stops dynamically as needed. See /etc/inetd.conf in the Utilities Reference.
- Defines the format for specifying variable names for SNMP utilities; see /etc/mib.txt in the Utilities Reference.
- Contains an ASCII message of the day that may be displayed when users
log in, as long as /etc/profile is configured to display
The default /etc/profile displays this file only if the /etc/motd file is more recent than the time you last logged in to the system, as determined by the time your $HOME/.lastlogin file was last modified. For more information, see the description of /etc/profile in Configuring Your Environment.
- Network name database file. For more information, see /etc/networks in the Utilities Reference.
- Backup of /etc/passwd file before its last change via the passwd utility. See the Managing User Accounts chapter.
- Backup of /etc/shadow file before its last change via the passwd utility. See Managing User Accounts.
- Configuration file for SNMP v2 party definitions. See /etc/party.conf in the Utilities Reference for more details.
- This file defines login accounts. See the chapter Logging In, Logging Out, and Shutting Down, as well as Managing User Accounts for more details; also, see passwd, login, phlogin2, and phlogin in the Utilities Reference.
- A directory that contains some Photon-related configuration files,
- Configuration files for pterm.
- A directory that contains the default configuration file for the shelf, and the default layout of the Launch menu.
- An optional directory where you can put configuration files for phlogin2 or phlogin.
- Configuration files for the window manager, pwm.
For more information, see Using the Photon microGUI.
- A directory that contains printertype.cfg files and a fontmap file used by the phs-to-ps utility. For more information, see "Printing with spooler" in the Printing chapter.
- The startup profile script executed by the shell when you log in; it's executed before $HOME/.profile. See Configuring Your Environment.
- A directory where the default /etc/profile script looks for scripts to run when any user logs in. The /etc/profile script runs each script in this directory that matches *.$(SHELL##*/}. For example, if the value of the SHELL environment variable is /bin/sh, the script runs the scripts that match *.sh.
- A directory where you usually keep local system-initialization files. For more information, see the description of /etc/system/sysinit in Controlling How Neutrino Starts.
- Resolver configuration file; see also /etc/hosts, above. See /etc/resolv.conf in the Utilities Reference.
- A directory that holds the default version of .profile. When you add a new user to the system, this file is copied to the user's home directory. For more information, see the description of /etc/default/passwd in the documentation for passwd, and the description of .profile in Configuring Your Environment.
- A directory that includes files and directories used when you boot
the system, including:
- /etc/system/sysinit -- the main script for initializing the system.
- /etc/system/config/nophoton -- a file indicating that you don't want to start Photon.
- /etc/system/config/useqnet -- a file indicating that you want to start Qnet. For more information, see the Using Qnet for Transparent Distributed Processing chapter.
- /etc/system/enum -- the location of configuration files for the enumerators. For more information, see the Controlling How Neutrino Starts chapter.
For more information, see the Controlling How Neutrino Starts chapter.
- A directory where phlocale looks for a list of possible time zones; see "Setting the time zone" in Configuring Your Environment.
- CD-ROM filesystems.
- Floppy disk filesystems.
- Filesystems on hard disk partitions.
The home directories of regular users are found here. The name of your home directory is often the same as your user name.
A directory that contains essential shared libraries that programs need in order to run (filename.so), as well as static libraries used during development. See also /usr/lib and /usr/local/lib.
The /lib directory includes:
- Contains additional shared libraries that implement OS drivers and services, such as drivers, filesystem managers, and so on. For some examples of how shared libraries are used for certain types of drivers and services, see Filesystems, Native Networking (Qnet), and TCP/IP Networking in the System Architecture guide. For details about specific shared objects in the /lib/dll directory, see their respective entries in the Utilities Reference.
Owned by the process manager (procnto), this virtual directory can give you information about processes and pathname-space configuration.
The /proc directory contains a subdirectory for each process; the process ID is used as the name of the directory. These directories each contain an entry (as) that defines the process's address space. Various utilities use this entry to get information about a process.
The /proc directory also includes:
- The image filesystem that comprises the boot image. For more information, see Making an OS Image in Building Embedded Systems.
- A special entry that receives notification when a process terminates abnormally.
- The address space for yourself (i.e. for the process that's making the query).
- Pathname-space mountpoints.
If you list the contents of the /proc directory, /proc/mount doesn't show up, but you can list the contents of /proc/mount.
The /root directory is the home directory for the root user.
This directory contains essential system binaries, including:
- drivers (e.g. devb*, devc*, devf*, devp*, devu*)
- enumerators (e.g. enum-devices)
- initialization programs (e.g. diskboot, seedres)
- configuration utilities (e.g. dinit) and repair utilities (e.g. chkfsys, chkdosfs)
- managers (e.g. io-net, mqueue, pipe)
Many of these files are used when you boot the system; for more information, see Controlling How Neutrino Starts.
This directory contains temporary files. Programs are supposed to remove their temporary files after using them, but sometimes they don't, either due to poor coding or abnormal termination. You can periodically clean out extraneous temporary files when your system is idle.
The /usr directory is a secondary file hierarchy that contains shareable, read-only data, and includes:
- A directory that contains most user commands, such as diff, errno, and wc.
- A directory that contains the documentation (in the product directory) and common images (in the lib/images directory). For more information, see "Getting help with the Helpviewer" in Using the Photon microGUI, and helpviewer in the Utilities Reference.
- The top of a directory structure that contains the C and C++ header files. This directory includes sys, platform-specific, and other directories.
- Documentation for various utilities.
- Object files, libraries, and internal binaries that you shouldn't execute directly or in scripts. You'll link against these libraries if you write any programs.
- A directory that could contain system daemons and system utilities; in general, these are run only by other programs.
- A directory where the system administrator can install software locally. It's initially empty.
- "Manual pages" for various utilities.
- The top of a directory structure that contains executables, data files, and so on, associated with Photon.
- The top of a directory structure that contains executables, data files, plugins, etc. associated with the Integrated Development Environment (IDE), which is shipped as part of the QNX Momentics Professional Edition.
- Nonessential system binaries, such as cron, dumper, and nicinfo.
- Data that's independent of the architecture, such as icons, backdrops, and various gawk programs.
- A directory for source code.
The /var directory contains variable data files, including cache files, lock files, log files, and the following:
- The directory where dumper saves any dumps that result when a program terminates abnormally.
- The default spill directory for the package filesystem (if you're using it -- it isn't used by default). For more information, see "Spill directory" in Working with Filesystems.
Each file and directory belongs to a specific user ID and group ID, and has a set of permissions (also referred to as modes) associated with it. You can use these utilities to control ownership and permissions:
|Specify the permissions for a file or directory||chmod|
|Change the owner (and optionally the group) for a file or directory||chown|
|Change the group for a file or directory||chgrp|
For details, see the Utilities Reference.
|You can change the permissions and ownership for a file or directory only if you're its owner or you're logged in as root. If you want to change both the permissions and the ownership, change the permissions first. Once you've assigned the ownership to another user, you can't change the permissions.|
Permissions are divided into these categories:
- Permissions for the user (i.e. the owner)
- Permissions for the group.
- Permissions for others (i.e. everyone who isn't in the group).
Each set of permissions includes:
- Read permission.
- Write permission.
- Execute permission. For a directory, this is permission to list or search the directory.
- s or S
- Setuid or setgid (see below).
- t or T
- Sticky bit (see below).
For example, if you list your home directory (using ls -al), you might get output like this:
total 94286 drwxr-xr-x 18 barney techies 6144 Sep 26 06:37 ./ drwxrwxr-x 3 root root 2048 Jul 15 07:09 ../ drwx------ 2 barney techies 4096 Jul 04 11:17 .AbiSuite/ -rw-rw-r-- 1 barney techies 185 Oct 27 2000 .Sig -rw------- 1 barney techies 34 Jul 05 2002 .cvspass drwxr-xr-x 2 barney techies 2048 Feb 26 2003 .ica/ -rw-rw-r-- 1 barney techies 320 Nov 11 2002 .kshrc -rw-rw-r-- 1 barney techies 0 Oct 02 11:17 .lastlogin drwxrwxr-x 3 barney techies 2048 Oct 17 2002 .mozilla/ drwxrwxr-x 11 barney techies 2048 Sep 08 09:08 .ph/ -rw-r--r-- 1 barney techies 254 Nov 11 2002 .profile drwxrwxr-x 2 barney techies 4096 Jul 04 09:06 .ws/ -rw-rw-r-- 1 barney techies 3585 Dec 05 2002 123.html
The first column is the set of permissions. A leading d indicates that the item is a directory; see "Types of files," earlier in this chapter.
You can also use octal numbers to indicate the modes; see chmod in the Utilities Reference.
Some programs, such as passwd, need to run as a specific user in order to work properly:
$ which -l passwd -rwsrwxr-x 1 root root 21544 Mar 30 23:34 /usr/bin/passwd
Notice that the third character in the owner's permissions is s. This indicates a setuid ("set user ID") command; when you run passwd, the program runs as the owner of the file (i.e. root). An S means that the setuid bit is set for the file, but the execute bit isn't set.
You might also find some setgid ("set group ID") commands, which run with the same group ID as the owner of the file, but not with the owner's user ID. If setgid is set on a directory, files created in the directory have the directory's group ID, not that of the file's creator. This scheme is commonly used for spool areas, such as /usr/spool/mail, which is setgid and owned by the mail group, so that programs running as the mail group can update things there, but the files still belong to their normal owners.
|If you change the ownership of a setuid command, the setuid bit is cleared, unless you're logged in as root. Similarly, if you change the group of a setgid command, the setgid bit is cleared, unless you're root.|
|Setuid and setgid commands can cause a security problem. If you create any, make sure that only the owner can write them, and that a malicious user can't hijack them -- especially if root owns them.|
The sticky bit is an access permission that affects the handling of executable files and directories:
- If it's set for an executable file, the kernel keeps the executable in memory for "a while" after the program ends -- the exact length of time depends on what else is happening in the system. This can improve the performance if you run a program (e.g. a compiler or linker) frequently.
- For a directory, it affects who can delete a file in the directory. You always need to have write permission on the directory, but if the sticky bit is set for the directory, you also need to be the owner of the file or directory or have write permission on the file.
If the third character in a set of permissions is t (e.g. r-t), the sticky bit and execute permission are both set; T indicates that only the sticky bit is set.
Use the umask command to specify the mask for setting the permissions on new files. The default mask is 002, so any new files give read and write permission to the user (i.e. the owner of the file) and the rest of the user's group, and read permission to other users. If you want to remove read and write permissions from the other users, add this command to your .profile:
If you're the system administrator, and you want this change to apply to everyone, change the umask setting in /etc/profile. For more information about profiles, see Configuring Your Environment.
This table lists some common filename extensions used in a Neutrino system:
|.1||Troff-style text, e.g. from UNIX "man" (manual) pages.||man and troff in the third-party repository|
|.b||Bench calculator library or program||bc|
|.bat||MS-DOS batch file||For use on DOS systems; won't run under Neutrino. See Writing Shell Scripts and ksh for information on writing shell scripts for Neutrino.|
|.bmp||Bitmap graphical image||pv (Photon viewer)|
|.build||OS image buildfile||mkifs|
|.c||C program source code||qcc, make (QNX Momentics development system required)|
|.C, .cc, .cpp||C++ program source code||QCC, make (QNX Momentics development system required)|
|.cfg||Configuration files, various formats||Various programs; formats differ|
|.conf||Configuration files, various formats||Various program; formats differ|
|.css||Cascading style sheet||Used in the QNX Momentics PE development system for Eclipse documentation|
|.def||C++ definition file||QCC, make (QNX Momentics development system required)|
|.dll||MS-Windows dynamic link library||Not used directly in Neutrino; necessary in support of some programs that run under MS-Windows, such as some of the QNX Momentics development tools. See .so (shared objects) for the Neutrino equivalent.|
|.gif||GIF graphical image||pv (Photon viewer)|
|.gz||Compressed file||gzip; Backing Up and Recovering Data|
|.h||C header file||qcc, make (QNX Momentics development system required)|
|.htm||HyperText Markup Language (HTML) file for Web viewing||voyager web browser|
|.html||HyperText Markup Language (HTML) file for Web viewing||helpviewer, voyager web browser|
|.ifs, .img||A QNX Image filesystem, typically a bootable image||mkifs; see also Making an OS Image in Building Embedded Systems (QNX Momentics development system)|
|.jar||Java archive, consisting of multiple java files (class files etc.) compressed into a single file||Java applications e.g. the QNX Momentics PE IDE|
|.jpg||JPEG graphical image||pv (Photon viewer)|
|.kbd||Compiled Photon keyboard definition files||Photon, mkkbd|
|.kdef||Source Photon keyboard definition files||mkkbd|
|.mk||Makefile source, typically used within QNX recursive makes||make (QNX Momentics development system)|
|.o||Binary output file that results from compiling a C, C++, or Assembly source file||qcc, make (QNX Momentics development system)|
|.pal||Photon palette file||Photon|
|.pfr||Bitstream TrueDoc Portable Font Resource file||phfont|
|.phf||Bitmapped font file||phfont|
|.qpr||Neutrino installation package repository; a gzipped tar archive of .qpm, .qpk, and .qrm files||qnxinstall|
|.qpm||Neutrino package manifest||Usually found in a package repository (.qpr); qnxinstall|
|.qpk||Neutrino package contents||Usually found in a package repository (.qpr); qnxinstall|
|.qrm||Neutrino package repository manifest||Usually found in a package repository (.qpr); qnxinstall|
|.S, .s||Assembly source code file||GNU assembler as (QNX Momentics development system)|
|.so, .so.n||Shared object||qcc, make (QNX Momentics development system)|
|.tar||Tape archive||tar; Backing Up and Recovering Data|
|.tar.gz, .tgz||Compressed tape archive||gzip, tar; Backing Up and Recovering Data|
|.toc||Helpviewer table of contents file||helpviewer|
|.txt||ASCII text file||Many text-based editors, applications, and individual users|
|.ttf||TrueType font file||phfont|
|.use||Usage message source for programs that don't embed usage in the program source code (QNX recursive make)||make (QNX Momentics development suite)|
|.wav||Audio wave file||phplay|
|.xml||Extensible Markup Language file; multiple uses, including IDE documentation in a QNX Momentics PE development system|
|.zip||Compressed archive file||gzip|
If you aren't sure about the format of a file, use the file utility:
Here are a few problems that you might have with files:
- I'm trying to write a file, but I get a "permission denied" message.
- You don't have write permission for the file. If you're the owner (or root) you can change the permissions; see "File ownership and permissions," above.
- I'm trying to list a directory that I have write permission for, but I get a "permission denied" message.
- You need to have read or execute permission for a directory in order to list it. See "File ownership and permissions," above.
- I'm having trouble with a file that has a space in its name.
- The command interpreter, or shell, parses the command line and uses the space character to break the command into tokens. If your filename includes a space, you need to "quote" the space so that the shell knows you want a literal space. For more information, including other special characters that you need to watch for, see "Quoting special characters" in Using the Command Line.