![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to 2.2.t CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 06.sysman|
Return to 2.2.t CVS log | Up to [CSRG BSD Unix] / 43BSDReno / share / doc / ps1 / 06.sysman |
1.1 root 1: .\" Copyright (c) 1983 Regents of the University of California.
2: .\" All rights reserved. The Berkeley software License Agreement
3: .\" specifies the terms and conditions for redistribution.
4: .\"
5: .\" @(#)2.2.t 6.3 (Berkeley) 5/12/86
6: .\"
7: .sh "File system
8: .NH 3
9: Overview
10: .PP
11: The file system abstraction provides access to a hierarchical
12: file system structure.
13: The file system contains directories (each of which may contain
14: other sub-directories) as well as files and references to other
15: objects such as devices and inter-process communications sockets.
16: .PP
17: Each file is organized as a linear array of bytes. No record
18: boundaries or system related information is present in
19: a file.
20: Files may be read and written in a random-access fashion.
21: The user may read the data in a directory as though
22: it were an ordinary file to determine the names of the contained files,
23: but only the system may write into the directories.
24: The file system stores only a small amount of ownership, protection and usage
25: information with a file.
26: .NH 3
27: Naming
28: .PP
29: The file system calls take \fIpath name\fP arguments.
30: These consist of a zero or more component \fIfile names\fP
31: separated by ``/\^'' characters, where each file name
32: is up to 255 ASCII characters excluding null and ``/\^''.
33: .PP
34: Each process always has two naming contexts: one for the
35: root directory of the file system and one for the
36: current working directory. These are used
37: by the system in the filename translation process.
38: If a path name begins with a ``/\^'', it is called
39: a full path name and interpreted relative to the root directory context.
40: If the path name does not begin with a ``/\^'' it is called
41: a relative path name and interpreted relative to the current directory
42: context.
43: .PP
44: The system limits
45: the total length of a path name to 1024 characters.
46: .PP
47: The file name ``..'' in each directory refers to
48: the parent directory of that directory.
49: The parent directory of the root of the file system is always that directory.
50: .PP
51: The calls
52: .DS
53: chdir(path);
54: char *path;
55:
56: chroot(path)
57: char *path;
58: .DE
59: change the current working directory and root directory context of a process.
60: Only the super-user can change the root directory context of a process.
61: .NH 3
62: Creation and removal
63: .PP
64: The file system allows directories, files, special devices,
65: and ``portals'' to be created and removed from the file system.
66: .NH 4
67: Directory creation and removal
68: .PP
69: A directory is created with the \fImkdir\fP system call:
70: .DS
71: mkdir(path, mode);
72: char *path; int mode;
73: .DE
74: where the mode is defined as for files (see below).
75: Directories are removed with the \fIrmdir\fP system call:
76: .DS
77: rmdir(path);
78: char *path;
79: .DE
80: A directory must be empty if it is to be deleted.
81: .NH 4
82: File creation
83: .PP
84: Files are created with the \fIopen\fP system call,
85: .DS
86: fd = open(path, oflag, mode);
87: result int fd; char *path; int oflag, mode;
88: .DE
89: The \fIpath\fP parameter specifies the name of the
90: file to be created. The \fIoflag\fP parameter must
91: include O_CREAT from below to cause the file to be created.
92: Bits for \fIoflag\fP are
93: defined in \fI<sys/file.h>\fP:
94: .DS
95: ._d
96: #define O_RDONLY 000 /* open for reading */
97: #define O_WRONLY 001 /* open for writing */
98: #define O_RDWR 002 /* open for read & write */
99: #define O_NDELAY 004 /* non-blocking open */
100: #define O_APPEND 010 /* append on each write */
101: #define O_CREAT 01000 /* open with file create */
102: #define O_TRUNC 02000 /* open with truncation */
103: #define O_EXCL 04000 /* error on create if file exists */
104: .DE
105: .PP
106: One of O_RDONLY, O_WRONLY and O_RDWR should be specified,
107: indicating what types of operations are desired to be performed
108: on the open file. The operations will be checked against the user's
109: access rights to the file before allowing the \fIopen\fP to succeed.
110: Specifying O_APPEND causes writes to automatically append to the
111: file.
112: The flag O_CREAT causes the file to be created if it does not
113: exist, owned by the current user
114: and the group of the containing directory.
115: The protection for the new file is specified in \fImode\fP.
116: The file mode is used as a three digit octal number.
117: Each digit encodes read access as 4, write access as 2 and execute
118: access as 1, or'ed together. The 0700 bits describe owner
119: access, the 070 bits describe the access rights for processes in the same
120: group as the file, and the 07 bits describe the access rights
121: for other processes.
122: .PP
123: If the open specifies to create the file with O_EXCL
124: and the file already exists, then the \fIopen\fP will fail
125: without affecting the file in any way. This provides a
126: simple exclusive access facility.
127: If the file exists but is a symbolic link, the open will fail
128: regardless of the existence of the file specified by the link.
129: .NH 4
130: Creating references to devices
131: .PP
132: The file system allows entries which reference peripheral devices.
133: Peripherals are distinguished as \fIblock\fP or \fIcharacter\fP
134: devices according by their ability to support block-oriented
135: operations.
136: Devices are identified by their ``major'' and ``minor''
137: device numbers. The major device number determines the kind
138: of peripheral it is, while the minor device number indicates
139: one of possibly many peripherals of that kind.
140: Structured devices have all operations performed internally
141: in ``block'' quantities while
142: unstructured devices often have a number of
143: special \fIioctl\fP operations, and may have input and output
144: performed in varying units.
145: The \fImknod\fP call creates special entries:
146: .DS
147: mknod(path, mode, dev);
148: char *path; int mode, dev;
149: .DE
150: where \fImode\fP is formed from the object type
151: and access permissions. The parameter \fIdev\fP is a configuration
152: dependent parameter used to identify specific character or
153: block I/O devices.
154: .NH 4
155: Portal creation\(dg
156: .PP
157: .FS
158: \(dg The \fIportal\fP call is not implemented in 4.3BSD.
159: .FE
160: The call
161: .DS
162: fd = portal(name, server, param, dtype, protocol, domain, socktype)
163: result int fd; char *name, *server, *param; int dtype, protocol;
164: int domain, socktype;
165: .DE
166: places a \fIname\fP in the file system name space that causes connection to a
167: server process when the name is used.
168: The portal call returns an active portal in \fIfd\fP as though an
169: access had occurred to activate an inactive portal, as now described.
170: .PP
171: When an inactive portal is accessed, the system sets up a socket
172: of the specified \fIsocktype\fP in the specified communications
173: \fIdomain\fP (see section 2.3), and creates the \fIserver\fP process,
174: giving it the specified \fIparam\fP as argument to help it identify
175: the portal, and also giving it the newly created socket as descriptor
176: number 0. The accessor of the portal will create a socket in the same
177: \fIdomain\fP and \fIconnect\fP to the server. The user will then
178: \fIwrap\fP the socket in the specified \fIprotocol\fP to create an object of
179: the required descriptor type \fIdtype\fP and proceed with the
180: operation which was in progress before the portal was encountered.
181: .PP
182: While the server process holds the socket (which it received as \fIfd\fP
183: from the \fIportal\fP call on descriptor 0 at activation) further references
184: will result in connections being made to the same socket.
185: .NH 4
186: File, device, and portal removal
187: .PP
188: A reference to a file, special device or portal may be removed with the
189: \fIunlink\fP call,
190: .DS
191: unlink(path);
192: char *path;
193: .DE
194: The caller must have write access to the directory in which
195: the file is located for this call to be successful.
196: .NH 3
197: Reading and modifying file attributes
198: .PP
199: Detailed information about the attributes of a file
200: may be obtained with the calls:
201: .DS
202: #include <sys/stat.h>
203:
204: stat(path, stb);
205: char *path; result struct stat *stb;
206:
207: fstat(fd, stb);
208: int fd; result struct stat *stb;
209: .DE
210: The \fIstat\fP structure includes the file
211: type, protection, ownership, access times,
212: size, and a count of hard links.
213: If the file is a symbolic link, then the status of the link
214: itself (rather than the file the link references)
215: may be found using the \fIlstat\fP call:
216: .DS
217: lstat(path, stb);
218: char *path; result struct stat *stb;
219: .DE
220: .PP
221: Newly created files are assigned the user id of the
222: process that created it and the group id of the directory
223: in which it was created. The ownership of a file may
224: be changed by either of the calls
225: .DS
226: chown(path, owner, group);
227: char *path; int owner, group;
228:
229: fchown(fd, owner, group);
230: int fd, owner, group;
231: .DE
232: .PP
233: In addition to ownership, each file has three levels of access
234: protection associated with it. These levels are owner relative,
235: group relative, and global (all users and groups). Each level
236: of access has separate indicators for read permission, write
237: permission, and execute permission.
238: The protection bits associated with a file may be set by either
239: of the calls:
240: .DS
241: chmod(path, mode);
242: char *path; int mode;
243:
244: fchmod(fd, mode);
245: int fd, mode;
246: .DE
247: where \fImode\fP is a value indicating the new protection
248: of the file, as listed in section 2.2.3.2.
249: .PP
250: Finally, the access and modify times on a file may be set by the call:
251: .DS
252: utimes(path, tvp)
253: char *path; struct timeval *tvp[2];
254: .DE
255: This is particularly useful when moving files between media, to
256: preserve relationships between the times the file was modified.
257: .NH 3
258: Links and renaming
259: .PP
260: Links allow multiple names for a file
261: to exist. Links exist independently of the file linked to.
262: .PP
263: Two types of links exist, \fIhard\fP links and \fIsymbolic\fP
264: links. A hard link is a reference counting mechanism that
265: allows a file to have multiple names within the same file
266: system. Symbolic links cause string substitution
267: during the pathname interpretation process.
268: .PP
269: Hard links and symbolic links have different
270: properties. A hard link insures the target
271: file will always be accessible, even after its original
272: directory entry is removed; no such guarantee exists for a symbolic link.
273: Symbolic links can span file systems boundaries.
274: .PP
275: The following calls create a new link, named \fIpath2\fP,
276: to \fIpath1\fP:
277: .DS
278: link(path1, path2);
279: char *path1, *path2;
280:
281: symlink(path1, path2);
282: char *path1, *path2;
283: .DE
284: The \fIunlink\fP primitive may be used to remove
285: either type of link.
286: .PP
287: If a file is a symbolic link, the ``value'' of the
288: link may be read with the \fIreadlink\fP call,
289: .DS
290: len = readlink(path, buf, bufsize);
291: result int len; result char *path, *buf; int bufsize;
292: .DE
293: This call returns, in \fIbuf\fP, the null-terminated string
294: substituted into pathnames passing through \fIpath\fP\|.
295: .PP
296: Atomic renaming of file system resident objects is possible
297: with the \fIrename\fP call:
298: .DS
299: rename(oldname, newname);
300: char *oldname, *newname;
301: .DE
302: where both \fIoldname\fP and \fInewname\fP must be
303: in the same file system.
304: If \fInewname\fP exists and is a directory, then it must be empty.
305: .NH 3
306: Extension and truncation
307: .PP
308: Files are created with zero length and may be extended
309: simply by writing or appending to them. While a file is
310: open the system maintains a pointer into the file
311: indicating the current location in the file associated with
312: the descriptor. This pointer may be moved about in the
313: file in a random access fashion.
314: To set the current offset into a file, the \fIlseek\fP
315: call may be used,
316: .DS
317: oldoffset = lseek(fd, offset, type);
318: result off_t oldoffset; int fd; off_t offset; int type;
319: .DE
320: where \fItype\fP is given in \fI<sys/file.h>\fP as one of:
321: .DS
322: ._d
323: #define L_SET 0 /* set absolute file offset */
324: #define L_INCR 1 /* set file offset relative to current position */
325: #define L_XTND 2 /* set offset relative to end-of-file */
326: .DE
327: The call ``lseek(fd, 0, L_INCR)''
328: returns the current offset into the file.
329: .PP
330: Files may have ``holes'' in them. Holes are void areas in the
331: linear extent of the file where data has never been
332: written. These may be created by seeking to
333: a location in a file past the current end-of-file and writing.
334: Holes are treated by the system as zero valued bytes.
335: .PP
336: A file may be truncated with either of the calls:
337: .DS
338: truncate(path, length);
339: char *path; int length;
340:
341: ftruncate(fd, length);
342: int fd, length;
343: .DE
344: reducing the size of the specified file to \fIlength\fP bytes.
345: .NH 3
346: Checking accessibility
347: .PP
348: A process running with
349: different real and effective user ids
350: may interrogate the accessibility of a file to the
351: real user by using
352: the \fIaccess\fP call:
353: .DS
354: accessible = access(path, how);
355: result int accessible; char *path; int how;
356: .DE
357: Here \fIhow\fP is constructed by or'ing the following bits, defined
358: in \fI<sys/file.h>\fP:
359: .DS
360: ._d
361: #define F_OK 0 /* file exists */
362: #define X_OK 1 /* file is executable */
363: #define W_OK 2 /* file is writable */
364: #define R_OK 4 /* file is readable */
365: .DE
366: The presence or absence of advisory locks does not affect the
367: result of \fIaccess\fP\|.
368: .NH 3
369: Locking
370: .PP
371: The file system provides basic facilities that allow cooperating processes
372: to synchronize their access to shared files. A process may
373: place an advisory \fIread\fP or \fIwrite\fP lock on a file,
374: so that other cooperating processes may avoid interfering
375: with the process' access. This simple mechanism
376: provides locking with file granularity. More granular
377: locking can be built using the IPC facilities to provide a lock
378: manager.
379: The system does not force processes to obey the locks;
380: they are of an advisory nature only.
381: .PP
382: Locking is performed after an \fIopen\fP call by applying the
383: \fIflock\fP primitive,
384: .DS
385: flock(fd, how);
386: int fd, how;
387: .DE
388: where the \fIhow\fP parameter is formed from bits defined in \fI<sys/file.h>\fP:
389: .DS
390: ._d
391: #define LOCK_SH 1 /* shared lock */
392: #define LOCK_EX 2 /* exclusive lock */
393: #define LOCK_NB 4 /* don't block when locking */
394: #define LOCK_UN 8 /* unlock */
395: .DE
396: Successive lock calls may be used to increase or
397: decrease the level of locking. If an object is currently
398: locked by another process when a \fIflock\fP call is made,
399: the caller will be blocked until the current lock owner
400: releases the lock; this may be avoided by including LOCK_NB
401: in the \fIhow\fP parameter.
402: Specifying LOCK_UN removes all locks associated with the descriptor.
403: Advisory locks held by a process are automatically deleted when
404: the process terminates.
405: .NH 3
406: Disk quotas
407: .PP
408: As an optional facility, each file system may be requested to
409: impose limits on a user's disk usage.
410: Two quantities are limited: the total amount of disk space which
411: a user may allocate in a file system and the total number of files
412: a user may create in a file system. Quotas are expressed as
413: \fIhard\fP limits and \fIsoft\fP limits. A hard limit is
414: always imposed; if a user would exceed a hard limit, the operation
415: which caused the resource request will fail. A soft limit results
416: in the user receiving a warning message, but with allocation succeeding.
417: Facilities are provided to turn soft limits into hard limits if a
418: user has exceeded a soft limit for an unreasonable period of time.
419: .PP
420: To enable disk quotas on a file system the \fIsetquota\fP call
421: is used:
422: .DS
423: setquota(special, file)
424: char *special, *file;
425: .DE
426: where \fIspecial\fP refers to a structured device file where
427: a mounted file system exists, and
428: \fIfile\fP refers to a disk quota file (residing on the file
429: system associated with \fIspecial\fP) from which user quotas
430: should be obtained. The format of the disk quota file is
431: implementation dependent.
432: .PP
433: To manipulate disk quotas the \fIquota\fP call is provided:
434: .DS
435: #include <sys/quota.h>
436:
437: quota(cmd, uid, arg, addr)
438: int cmd, uid, arg; caddr_t addr;
439: .DE
440: The indicated \fIcmd\fP is applied to the user ID \fIuid\fP.
441: The parameters \fIarg\fP and \fIaddr\fP are command specific.
442: The file \fI<sys/quota.h>\fP contains definitions pertinent to the
443: use of this call.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.