Let us count the total number of EOF values in tire FAT array inside a FAT32 fil
ID: 3823233 • Letter: L
Question
Let us count the total number of EOF values in tire FAT array inside a FAT32 file system, and denote this number as N. Then, N is the same as the sum of all files and directories in the corresponding FAT32 file system. True or false? If false, you must state the reason(s) for the incorrectness. When a disk is full, the sum of the sizes of all files, including directories, is always equal to the sum of all data blocks. True or false? If false, you must state the reason(s) for the incorrectness. During the lectures, we know that when a file is opened, the kernel keeps track on two sets of attributes: file attributes and runtime attributes. In the following table of attributes, which are file attributes (stored on disk)? Which are runtime attributes (stored in kernel only)? Write your answer on the answer book.Explanation / Answer
g)
Answer: False
Explanatin:
A sector is a physical spot on a formatted disk that holds information.
When a disk is formatted, tracks are defined from inside to the outside of the disk platter.
Each track is divided into a slice, which is a sector.
On hard drives and floopy drives, each sector can hold 512 bytes of data.
A block is a group of sectors.
A block might be one sector, or it might be several sectors (2,4,8,16).
The bigger the drive, the more sectors that a block will hold.
Eg:
When a file is copied from a floppy to a hard drive, it will usually take up more disk space, because when files are stored on a disk,
they always use up a whole number of blocks. Any Un needed space at the end of a block is unused and wasted.
For example, say your hard drive has a block size of 4K, and you have a file that is 4.5K.
This requires 8K to store on your hard drive (2 whole blocks), but only 4.5K on a floppy.
So the additional 3.5k will be wasted and thats why N is not same as the sum of files and directories in the correesponding FAT32 file system.
h)
Answer: False
Explanatin:
A sector is a physical spot on a formatted disk that holds information.
When a disk is formatted, tracks are defined from inside to the outside of the disk platter.
Each track is divided into a slice, which is a sector.
On hard drives and floopy drives, each sector can hold 512 bytes of data.
A block is a group of sectors.
A block might be one sector, or it might be several sectors (2,4,8,16).
The bigger the drive, the more sectors that a block will hold.
Eg:
When a file is copied from a floppy to a hard drive, it will usually take up more disk space, because when files are stored on a disk,
they always use up a whole number of blocks. Any Un needed space at the end of a block is unused and wasted.
For example, say your hard drive has a block size of 4K, and you have a file that is 4.5K.
This requires 8K to store on your hard drive (2 whole blocks), but only 4.5K on a floppy.
So the additional 3.5k will be wasted and thats why sum of size of all files, including directories, MAY not be equal to sum of all data blocks.
i) File Attributes & runtime attributes.
1. File Size --> file attribute
You've been taught that hard disks contain files, but that's not the entire truth. Actually, hard drives contain one very, very big number expressed by a lot of single bits. But this interpretation doesn't make any sense to you nor your computer, because processing single big numbers isn't very common. Instead, computer splits it into smaller 'words' (8-bit, 16-bit, 32-bit or whatever) and uses that way.
Filesystem defines the way files are physically located on the disk. You can think of it like this: if you had a 10000-page book without any chapters, page numbers or line breaks, it would be very hard to use. Of course page numbers and chapter titles take up some space on the page, but they make using the book a lot easier and faster. If you want to jump to chapter, let's say, 42, you just look it up in the table of contents. Then you leaf through the book until you find the chapter you want. Your files are chapters and your filesystem is the book. Filesystem metadata, like file boundaries, filenames etc. takes up space too, but it's a comparably small amount of space, and it makes things work a lot faster.
If your "chapter" is empty, it can still have a heading or a page number, right? Empty file contains zero bytes of data. Metadata takes up space, but it's not a part of the file, but of the filesystem.
Windows Alternate Data Streams (ADS).
2. File opening mode --> runtime attribute (stores in kernel)
Explanation 'A':
Kernel-modeKernel-mode device drivers refer to a file by its object name.
This name is DosDevices together with the full path of the file.
For example, the object name of the C:WindowsExample.txt file is DosDevicesC:WindowsExample.txt. Then the object name is encapsulated into an OBJECT_ATTRIBUTES structure by calling the InitializeObjectAttributes function.
If the device driver is loaded early, the DosDevices namespace may not yet exist.
Therefore, the DosDevices namespace is inaccessible to the device driver because no drive letter is exposed.
The only part of the file system that is guaranteed to be available is the SystemRoot namespace. The SystemRoot namespace is mapped to the folder where the operation system is installed. For example, this folder may be C:Windows or D:Winnt.
To obtain a file handle, you can pass an OBJECT_ATTRIBUTES structure to the ZwCreateFile function. The DesiredAccess parameter can be set to either GENERIC_READ, GENERIC_WRITE, or GENERIC_ALL, depending on what you want to do. If you set the CreateOptions parameter to FILE_SYNCHRONOUS_IO_NONALERT or FILE_SYNCHRONOUS_IO_ALERT, the file system keeps track of the current file-position offset.
Therefore, you can sequentially read or write to the file later.
Additionally, you can access the file at a random location.
Explanation 'B':
In almost every high-level language, the function that opens a file is a wrapper around the corresponding kernel system call.
It may do other fancy stuff as well, but in contemporary operating systems, opening a file must always go through the kernel.
This is why the arguments of the fopen library function, or Python's open closely resemble the arguments of the open system call.
In addition to opening the file, these functions usually set up a buffer that will be consequently used with the read/write operations.
The purpose of this buffer is to ensure that whenever you want to read N bytes, the corresponding library call will return N bytes, regardless of whether the calls to the underlying system calls return less.
In Unix-like operating systems, a successful call to open returns a "file descriptor" which is merely an integer in the context of the user process.
This descriptor is consequently passed to any call that interacts with the opened file, and after calling close on it, the descriptor becomes invalid.
It is important to note that the call to open acts like a validation point at which various checks are made.
If not all of the conditions are met, the call fails by returning -1 instead of the descriptor, and the kind of error is indicated in errno.
The essential checks are:
Whether the file exists;
Whether the calling process is privileged to open this file in the specified mode.
This is determined by matching the file permissions, owner ID and group ID to the respective ID's of the calling process.
In the context of the kernel, there has to be some kind of mapping between the process' file descriptors and the physically opened files.
The internal data structure that is mapped to the descriptor may contain yet another buffer that deals with block-based devices, or an internal pointer that points to the current read/write position
3. File Seek--> File attribute
Reading files, and especially complex configuration files, is not something which is done from the kernel.
Reasons:
Selecting where and in what format to read/write data is a policy and policy does not belong to kernel. A userland daemon is much easier to replace with one that receives or sends the data over a network, generates or converts them from/to different format etc.
Filesystem operations need a user context (i.e.: current != NULL). You can't be sure you're in user context so you can't write something from (for example) an interrupt handler.
The kernel allows multiple filesystem namespaces for user processes. Which one should it use? How do you make sure it indeed uses the one you want?
Kernel should not depend on particular layout of a filesystem nor on availability of writable filesystem. The location of the file is a policy decision and policy decisions should be done in userspace. Maybe you want to dump the kernel output in a remote MySQL server tomorrow, that kind of policy is so much easier in userland.
Kernel code should be kept simple and stupid, because any bug in it is likely to have serious consequences. Working with files requires being aware of various locking issues and would add unnecessary complexity.
4. File permission --> both
Both the kernel and the filesystem play a role.
Permissions are stored in the filesystem, so there needs to be a place to store the information in the filesystem format.
Permissions are enforced and communicated to applications by the kernel, so the kernel must implement rules to determine what the information stored in the filesystem means.
“Unix file permissions” refer to a traditional permission system which involves three actions (read, write, execute) controlled via three role types (user, group, other). The job of the filesystem is to store 3×3=9 bits of information. The job of the kernel is to interpret these bits as permissions; in particular, when a process attempts an operation on a file, the kernel must determine, given the user and groups that the process is running as, the permission bits of the file, and the requested operation, whether to allow the operation.
Thanks.
Related Questions
Navigate
Integrity-first tutoring: explanations and feedback only — we do not complete graded work. Learn more.