Files in Operating System

Every computer program or application must store and retrieve the necessary information. However, here are some of the issues with how and why operating systems implement files. Let's start with the problems and then move on to the solution.

  • Problem No.1: However, when the process is running on the computer system, the application can only store a limited amount of data in its own address space. The storage capacity is limited in this case by the size of the virtual address space.
  • Problem No.2: Another significant issue is that when the process is terminated, the information is lost. And for many computer programs, the information stored must be kept for an extended period of time, if not forever.
  • Problem No.3: Another major issue is that multiple processes must access the information at the same time. Consider the following scenario: if we have an online telephone directory that is stored within the address space of a single process and can only be accessed by that process.

Solution: As a result, in order to solve this type of large problem, information must be made independent of any single process. Following the resolution of the aforementioned major issues, we now have three essential requirements for the long-term storage of critical information stored in computer applications:

Problem No. Solution
1 A large amount of data must be able to be stored.
2 The information must survive the end of the process that is using it.
3 Multiple processes must have concurrent access to the information.

The solution to all three of the aforementioned issues is to store information on discs and other external media in units known as files.

You will learn everything there is to know about files in the operating system, which is divided into the following sections:

File Structure

This guide will walk you through three of the most common file structures, each of which will be preceded by a brief explanation. Files can be organized in a variety of ways.

File Structure 1

file structure

The file in this instance is an unstructured sequence of bytes, as can be seen in the figure that is located above. Because of this, the operating system is completely oblivious to the contents of the file because all it can see are the bytes that make up the file.

File Structure 2

operating system file structure

Now, as you can see from the diagram that was just presented, this depicts the second structure of a file, where a file is defined as a sequence of records of a fixed length, each of which has some kind of internal structure.

The concept that a read operation brings back a record and that a write operation merely adds a record to the end of the file is fundamental to the concept that a file is a sequence of records.

File Structure 3

os file structure

Now, in the final structure of a file that you can see in the figure that was just presented, a file essentially consists of a tree of records, not necessarily all of the same length, and each record contains a key field in a fixed position in the record. You can see this structure of a file in the above figure. The only reason the tree is stored on the field is so that quick searches can be conducted to find a particular key.

File Access

There is only one type of file access that was supported by the early OS, which is called sequential access.

In sequential access file systems, a process could read all bytes and records in a file in order, starting at the beginning, but couldn't skip around and read them out of order.

Sequential files could be read as often as needed. Sequential files were very convenient when magnetic tape was the storage medium.

However, when discs were used as the storage medium for the required files, it became possible to read the bytes or records of a file out of order or to access any record by key rather than by position.

Files whose bytes or records can be read in any order are called random access files. Random access files are required and essential for many computer applications, e.g., database systems.

File Attributes

As you are aware, every file has a name and data. However, in addition to the file's name and data, OS associates some additional information with the file, such as the date and time the file was created, the file's size, and so on. These extra items related to the file are also known as "file attributes."

Essentially, the list of file attributes varies by system. The table below lists some common file attributes and their definitions:

File Attribute File Attribute Description
Protection Who can access the file and in what way
Password Needed just to access the file
Creator Person ID of the person who created the file
Owner Current owner
Read-only flag 0 for read/write and 1 for red only.
Archive flag 0 for has been backed up, and 1 for needs to be backed up.
ASCII/binary flag 0 for ASCII file and 1 for binary a file
Hidden flag Normal is 0, and don't display in listings is 1.
System flag 0 for normal files and 1 for system files
Random access flag 0 for sequential access only and 1 for random access
Temporary flag 0 means normal, and 1 means delete file on process exit.
Lock flags 0 for unlocked and non-zero for locked
Key length Number of bytes in the key field
Creation time The file's creation date and time
Time of last access Date and time the file was last accessed
Record length number of bytes in a record
Key position Offset of key within each record
Time of last change Date and time when the file was last changed
Current size Number of bytes in the file
Maximum size number of bytes, the file may grow to

Memory Mapped Files

As many computer programmers feel, accessing the files is cumbersome and inconvenient, mainly when compared to accessing ordinary memory.

Therefore, for all the reasons above, some OSs have provided a way to map the files into the address space of a running process.

Conceptually, we can imagine the existence of the following two new system calls:

  • map
  • unmap

From the above two new imagined system calls, the map gives a file name and a virtual address that causes the OS to map the file into the address space at the virtual address.

File mapping is most effective on computer systems that support segmentation. File mapping introduces the following three problems:

  • It is too hard for any computer system to know the exact length of any output file.
  • If one process maps a file and another opens it for conventional reading,If the first process modifies a page, then that change won't be reflected in the file on the disc until the page is evicted.
  • A file may be larger than a segment, or sometimes larger than the whole virtual address space.

File System Implementations

We will only be able to view the file system from the perspective of the user from this point forward. Now is the time to take a look at the file system from the perspective of the implementor.

Users are only concerned with the file system in terms of how files are named, which operations are allowed on them and which aren't, what the directory tree looks like, etc., whereas file system implementors are interested in how files and directories are stored, how disc space for the file system is managed, and how to make everything work efficiently and reliably.

File System Layout

In their most basic form, file systems are kept on the discs. The vast majority of discs are capable of being segmented into multiple partitions, each of which can house a separate file system.

Sector 0 of this disk's partition is referred to as the Master Boot Record (MBR), and it is this record that is utilized in the process of booting the computer system. The partition table is located at the very end of the Master Boot Record.

That partition table gives the starting and ending addresses of each partition on the disk.

Only one of those partitions in the table is designated as an active partition. In order for the Basic Input/Output System (BIOS) to read in and run the Master Boot Record (MBR) whenever the computer system is booted up.

The very first thing that the master boot record program does is locate the partition that is currently active. It then reads in what is known as the boot block, which is the partition's very first block, and then it executes it.

Now what happens is that the program that is present in the boot block loads the operating system that is stored in the partition.

Even if the partition does not have an operating system that is capable of being booted, it still begins with a boot block so that everything is consistent.

Operating System Quiz

« Previous Topic Next Tutorial »

Follow/Like Us on Facebook

Subscribe Us on YouTube