0% found this document useful (0 votes)
60 views

Given - Chapter 3 File Systems and File Hierarchy

The file system abstraction supports creation, deletion, and modification of files and organization of files into directories. It also controls access and manages disk space. A file system contains a superblock with configuration info, an i-node table with file attributes and block mappings, and data blocks for file contents. When a new file is created, the kernel allocates an i-node, fills it with file status, allocates data blocks, records their addresses in the i-node, and creates a directory entry linking the file name to the i-node number.

Uploaded by

Rose
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
60 views

Given - Chapter 3 File Systems and File Hierarchy

The file system abstraction supports creation, deletion, and modification of files and organization of files into directories. It also controls access and manages disk space. A file system contains a superblock with configuration info, an i-node table with file attributes and block mappings, and data blocks for file contents. When a new file is created, the kernel allocates an i-node, fills it with file status, allocates data blocks, records their addresses in the i-node, and creates a directory entry linking the file name to the i-node number.

Uploaded by

Rose
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 15

ICS 2305 Systems

Programming
Chapter 3 File Systems and the File
Hierarchy
3.1 File System Abstraction
 A file system is an abstraction that supports the creation, deletion,
and modification of les, and organization of files (les) into
directories. It also supports control of access to files and directories
and manages the disk space accorded to it.
 We tend to use the phrase le system to refer to a hierarchical, tree-
like structure whose internal nodes are directories and whose
external nodes are non-directory-files (or perhaps empty directories),
but a le system is actually the at structure sitting on a linear storage
device such as a disk partition.
3.2 The Principal Components of a UNIX File System

 Every file system has (at least) one superblock located at the
beginning of its allocated storage. The superblock contains all
of the information about how the file system is configured, such
as block size, block address range, and mount status. Copies of
the superblock are almost always stored in several other places
within a partition.
 Each file system in UNIX has at least one table that identifies
the les in it. The entries in this table are called i-nodes
(pronounced eye-nodes), and the indices of the i-nodes in this i-
node table are called i-numbers. The i-nodes contain the le
attributes and a map indicating where the blocks of the le are
located on the disk.
 Attributes include properties such as
 the owner,
 the group,
 the permissions allowed on the le and the le type,
 the number of links to the le
 the time of last modification,
 the time of last access,
 the time the attributes were last changed,
 the size in bytes of the le,
 the number of blocks used by the le, and
 the id
 I-nodes and the tables that use them are important components of the UNIX le
system. Modern file systems usually have multiple i-node tables. Every file system
separates the i-node tables from the data blocks. The data blocks are where file
 contents are stored.
How the Kernel Creates Files
Suppose that the current working directory is /home/sweiss/scratch, and the command
$ gcc -o testprog testprog.c is executed. Assuming that the program is compiled and
linked, and that I have write and execute permission for the directory
/home/sweiss/scratch, gcc will create the file named testprog in this directory.

This section answers the question, "What steps are taken by the kernel to create the file
testprog" on behalf of gcc? These steps can be outlined as follows:
1. The kernel creates an i-node for the le, if possible.
2. The kernel lls in the i-node with the le status.
3. The kernel allocates data blocks for the le and stores the le data in these blocks.
4. The kernel records the addresses of the data blocks in the i-node.
5. The kernel creates a directory entry in the scratch directory with the i-node
number and file name testprog.
3.3 Reading Directory Information:
getdents()

- “processDirectory()” opens a directory file for reading and then


uses “getdents()” to obtain every entry in the directory.

System call: int getdents( int fd, struct dirent* buf, int structSize )

reads the directory file with descriptor fd from its current position
and fills the structure pointed to be by buf with the next entry.

- The structure “dirent” is defined in “/usr/include/sys/dirent.h” and


contains the following fields:

NAME MEANING
d_ino the inode number
d_off the offset of the next directory entry
d_reclen the length of the directory entry structure
d_nam the length of the filename
Miscellaneous File Management System Calls

- a brief description of the following miscellaneous file management


system calls:

NAME Function

chown changes a file’s owner and/or group


chmod changes a file’s permission settings
dup duplicates a file descriptor
dup2 similar to dup
fchown works just like chown
fchmod works just like chmod
fcntl gives access to miscellaneous file characteristics
ftruncate works just like truncate
ioctl controls a device
link creates a hard link
mknod creates a special file
sync schedulers all file buffers to be flushed to disk
truncate truncates a file
Changing a File’s Owner and/or Group: chown(),
ichown() and fchown()

- “chown()” and “fchown()” change the owner and/or group of a file and
work like this:

System Call: int chown( const char* fileName, uid_t ownerId,


gid_t groupId )
int lchown( const char* fileName, uid_t ownerId,
git_t groupId )
int fchown( int fd, uid_t ownerId, gid_t groupId )

- “chown()” causes the owner and group IDs of fileName to be changed


to ownerId and groupId, respectively.

A value of -1 in a particular field means that its associated value


should remain unchanged.

lchown():changes the ownership of a symbolic link


fchown():takes an open descriptor as an argument instead of a filename.
Changing a File’s Owner and/or Group: chown(),
ichown() and fchown()

- Example, changed the group of the file “test.txt” from “music” to “cs”.
which has a group ID number of 62.

$ cat mychown.c ---> list the program.


main()
{
int flag;
flag = chown(“test.txt”, -1, 62 ); /* Leave user ID uchanged */
if ( flag == -1 ) perror(“mychown.c”);
}

$ ls -lg test.txt ---> examine file before the change.


-rw-r--r-- 1 glass music 3 May 25 11:42 test.txt
$ mychown ---> run program.
$ ls -lg test.txt ---> examine file after the change.
-rw-r--r-- 1 glass cs 3 May 25 11:42 test.txt
$-
Changing a File’s Permissions: chmod() and fchmod()

- “chmod()” and “fchmod()” change a file’s permission flags

System Call : int chmod( const char* fileName, int mode )


int fchmod( int fd, mode_t mode );

“chmod()” changes the mode of fileName to mode,


where mode is usually supplied as an octal number,

To change a file’s mode, you must either own it or be a super-user.

“fchmod()” works just like “chmod()” except that it takes an open


file descriptor as an argument instead of a filename.

They both return a value of -1 if unsuccessful, and a value of 0


otherwise.
Changing a File’s Permissions: chmod() and fchmod()

- changed the permission flags of the file “test.txt” to 600 octal,


which corresponds to read and write permission for the owner only:

$ cat mychmod.c ---> list the program.


main()
{
int flag;
flag = chmod(“test.txt”, 0600); /* Use an octal encoding */
if ( flag==-1 ) perror(“mychmod.c”);
}

$ ls -l test.txt ---> examine file before the change.


-rw-r--r-- 1 glass 3 May 25 11:42 test.txt
$ mychmod ---> run the program.
$ ls -l test.txt ---> examine file after the change.
-rw------- 1 glass 3 May 25 11:42 test.txt
$-
Duplicating a File Descriptor: dup() and dup2()

- “dup()”, “dup2()”
to duplicate file descriptors, and they work like this:

System call: int dup( int oldFd )


int dup2( int oldFd, int newFd )

“dup()” finds the smallest free file-descriptor entry and points it


to the same file to which oldFd points.

“dup2()” closes newFd if it’s currently active and then points it


to the same file to which oldFd points.

- the original and copied file descriptors share the same file pointer
and access mode.

- return the index of the new file descriptor if successful and a value of
-1 otherwise.
Duplicating a File Descriptor: dup() and dup2()

- I created a file called “test.txt” and wrote to it via four different file
descriptors:

The first file descriptor was the original descriptor.

The second descriptor was a copy of the first, allocated in slot 4.

The third descriptor was a copy of the first, allocated in slot 0


( the standard input channel ), which was freed by the “close(0)”
statement.

The fourth descriptor was a copy of the third descriptor,


copied over the existing descriptor in slot 2
( the standard error channel ).
Duplicating a File Descriptor: dup() and dup2()
$ cat mydup.c ---> list the file.
#include <stdio.h>
#include <fcntl.h>
main()
{
int fd1, fd2, fd3;
fd1 = open( “test.txt”, O_RDWR | O_TRUNC );
printf(“fd1 = %d”\n”, fd1 );
write( fd1, “what’s “, 6 );
fd2 = dup(fd1); /* Make a copy of fd1 */
printf( “fd2=%d\n”, fd2);
write( fd2, “up”, 3 );
close(0); /* Close standard input */
fd3 = dup(fd1); /* Make another copy of fd1 */
printf(“fd3 = %d\n”, fd3);
write(0, “ doc“, 4);
dup2(3,2); /* Duplicate channel 3 to channel 2 */
write(2, “?\n”, 2 );
}

You might also like