Unix File And

Total Page:16

File Type:pdf, Size:1020Kb

Unix File And Outline ❚ Basics of File Systems Unix File and I/O ❚ Directory and Unix File System: inode ❚ UNIX I/O System Calls: open, close, read, write, ioctl (USP Chapters 4 and 5) ❚ File Representations: FDT, SFT, inode table ❚ fork and inheritance, Filters and redirection ❚ File pointers and buffering Instructor: Dr. Tongping Liu ❚ Directory operations ❚ Links of Files: Hard vs. Symbolic 1 2 Storing Information File Systems ❚ Applications may store information in the process ❚ For long-term information storage: address space. But it is a bad idea. Ø Should be able to store very large amount of information Ø Size is limited to size of virtual address space Ø Information must survive the processes of using it ü May not be sufficient, e.g. airline reservations, banking Ø Should provide concurrent accesses to multiple processes Ø The data is lost when the application terminates ❚ Solution: ü Even when a computer doesn’t crash! Ø Store information to disks in units called as “files” Ø Multiple processes might want to access the same data Ø Files are persistent until users delete it explicitly ü Imagine a telephone directory of one company Ø Files are managed by the OS ❚ File Systems: How the OS manages files! Refer the slides of Profs. Sirer and George at Cornell 1 File Naming File Attributes ❚ Motivation: ❚ File-specific info maintained by the OS Ø People cannot remember block, sector, … Ø File size, modification date, creation time, etc. Ø Varies a lot across different OSs Ø They should have human-readable names ❚ Some examples: ❚ Basic idea: Ø Name – human-readable form Ø Process creates a file, and gives it a name Ø Identifier – a unique tag (number) identifies a file within the file system ü Other processes can access the file by the name Ø Type – required for systems supporting different types (e.g. ro, exe) Ø Naming conventions are OS dependent Ø Location – pointer to the file location on device Ø Size ü Usually names are allowed to be less than 255 characters Ø Protection – controls who can read, write, execute the file ü Digits and special characters are sometimes allowed Ø Time, date, and user identification – data for protection, security, and ü MS-DOS and Windows are not case sensitive, but UNIX-like OSs are usage monitoring File Protection Access Example in Linux ❚ File owner/creator should be able to control: ❚ Mode of access: read, write, execute Ø what can be done ❚ Three classes of users: Ø by whom Ø Owner: Ø Group: ❚ Types of access Ø Public: RWX Ø Read 7: 1 1 1 Ø Write owner!group! public! 6: 1 1 0 Ø Execute chmod! game! 1: 0 0 1 Ø Append 761! Ø Delete Ø List 2 Outline Directory: An Example ❚ Basics of File Systems ❚ Directory and Unix File System: inode (SGG 12) ❚ UNIX I/O System Calls: open, close, read, write, ioctl ❚ File Representations: FDT, SFT, inode table ❚ fork and inheritance, Filters and redirection ❚ File pointers and buffering ❚ Directory operations ❚ Links of Files: Hard vs. Symbolic An example tree structure of the file system. 9 10 Structure of a Unix File System Definition of inode ❚ The inode is a data structure in a Unix-style file system that describes a filesystem object, such as a file or directory. ❚ Each inode stores the attributes and disk block location(s) of the object's data. ❚ Inode attributes may include metadata (times of last change, access, modification), as well as owner and permission data. A directory entry contains only a name and an index into a table with the information of a file (inode) 11 12 3 More about “inode” Traditional inode Structure ❚ Each file system (such as ext2 or ext3) maintains an array of inodes-- the inode table, which contains list of all files. Each individual inode has a unique number (unique to that filesystem): the inode number. ❚ An inode stores: Pointers to location of file Ø File type: regular file, directory, pipe etc. Ø Permissions to that file: read, write, execute Ø Link count: The number of hard link relative to an inode Ø User ID: owner of file Ø Group ID: group owner Ø Size of file: or major/minor number in case of some special files Ø Time stamp: access time, modification time and (inode) change time Ø Attributes: immutable' for example Ø Access control list: permissions for special users/groups Ø Link to location of file Ø Other metadata about the file 13 14 File Size and Block Size File Size and Block Size ❚ Block size is 8K and pointers are 4 bytes ❚ Block size is 8K and pointers are 8 bytes ❚ One single indirect pointer Ø How large a file can be represented using only one single Ø A block contains 2K pointers to identify file’s 2K blocks indirect pointer? Ø File size = 2K * 8K = 16MB Ø What about one double indirect pointer? ❚ One double indirect pointer Ø What about one triple indirect pointer? Ø 2K pointers à 2K blocks, where each block contains 2K pointers to identify blocks for the file Ø Number of blocks of the file = 2K*2K = 4M Ø File size = 4M * 8K = 32 GB ❚ One triple indirect pointer Ø Number of blocks of the file = 2K*2K*2K = 8 *K*K*K Ø File size à 64 TB ( = 2^33) ; 15 16 4 Outline Unix I/O Related System Calls ❚ Basics of File Systems ❚ Device independence: uniform device interface ❚ Directory and Unix File System: inode ❚ I/O through device drivers with standard interface ❚ UNIX I/O System Calls: open, close, read, write, ioctl ❚ Use file descriptors (FDs) ❚ File Representations: FDT, SFT, inode table Ø FD is an abstract indicator (handle) used to access a file or other input/output resource ❚ fork and inheritance, Filters and redirection ❚ 3 file descriptors open when a program starts ❚ File pointers and buffering Ø STDIN_FILENO (0), STDOUT_FILENO (1), ❚ Directory operations STDERR_FILENO (2) ❚ Links of Files: Hard vs. Symbolic ❚ 6 main system calls for I/O Ø open, close, read, write, ioctl, lseek Ø Return -1 on error and set errno 17 18 File position open ❚ An open file has its file position that keeps track of #include <fcntl.h> where the next character is to be read or written. #include <sys/stat.h> Ø On GNU systems, and all POSIX.1 systems, the file int open(const char *path, int oflag); position is simply an integer representing the number of bytes from the beginning of the file. int open(const char *path, int oflag, Ø The file position is normally set to the beginning of the file mode_t mode); when it is opened, and each time a character is read or written, the file position is incremented. In other words, accessing to a file is normally sequential. ❚ Oflag: O_RDONLY, O_WRONLY, O_RDWR, O_APPEND, O_CREAT, O_EXCL, O_NOCTTY, Ø File position can be changed by lseek O_NONBLOCK, O_TRUNC; 19 20 5 open (cont.) ❚ O_CREAT flag: must use the 3-parameter form of open and specify permissions POSIX Symbolic Names for Permissions (mode) defined in sys/stat.h Historical layout of the permissions mask. 21 22 Program 4.9 (p106): copyfilemain.ccopy a file. close and its usage #include <unistd.h> int close(int fildes); ❚ Open files are closed when program exits normally. 23 24 6 System Call: read An example to read in a line #include <unistd.h> ssize_t read(int fildes, void *buf, Read one char at a time! size_t nbyte); ❚ Need to allocate a buffer *buf to hold the bytes read; ❚ size_t is an unsigned long type; ❚ ssize_t is a signed long type; ❚ Can return fewer bytes than requested; ❚ Return value of -1 with errno set to EINTR is not usually an error. 25 26 System Call: write Example for write ?? Function copyfile reads from one file and writes out to another #include <unistd.h> ssize_t write(int fildes, const void *buf, size_t nbyte); ❚ Not error if return value > 0 but less than nbyte Ø Must restart write if it returns fewer bytes than requested ❚ Return value of -1 with errno set to EINTR is not an error usually 27 28 7 Outline File Representation ❚ Basics of File Systems ❚ File Descriptor Table: ❚ Directory and Unix File System: inodes Ø An array of pointers indexed by the file descriptors ❚ UNIX I/O System Calls: open, close, read, write, ioctl Ø The pointers point to entries in System File Table ❚ File Representations: FDT, SFT, inode table ❚ System File Table: Ø Contains entries for each opened file ❚ fork and inheritance, Filters and redirection Ø Entries contain pointers to a table of inodes kept in ❚ File pointers and buffering memory ❚ Directory operations Ø Other information in an entry: current file offset; file ❚ Links of Files: Hard vs. Symbolic mode; count of file descriptors using this entry; Ø When a file is closed, the count is decremented. The entry is freed when the count becomes 0. ❚ In-Memory Inode Table: copies of in-use inodes 29 30 File Representation (cont.) What Happened for File Read/Write 1. The process passes the file descriptor to the kernel through a system call (read/write) Per Process 2. The kernel will access the entry in file table on behalf of the process, by getting the pointer to the inode All Processes 3. For read/write, after obtaining the file pointer (offset) in the file table, then it can compute the All Processes block/sector information. 4. In the end, it will issue IO request. IO scheduler may combine multiple requests with the close Figure 4.2 (page 120): Relationship between the file descriptor table, the system file table and the in-memory inode table.
Recommended publications
  • STAT 625: Statistical Case Studies 1 Our Computing Environment(S)
    John W. Emerson, Department of Statistics, Yale University © 2013 1 STAT 625: Statistical Case Studies John W. Emerson Yale University Abstract This term, I’ll generally present brief class notes and scripts, but much of the lecture material will simply be presented in class and/or available online. However, student participation is a large part of this course, and at any time I may call upon any of you to share some of your work. Be prepared. This won’t be a class where you sit and absorb material. I strongly encourage you to work with other students; you can learn a lot from each other. To get anything out of this course you’ll need to put in the time for the sake of learning and strengthening your skills, not for the sake of jumping through the proverbial hoop. Lesson 1: Learning how to communicate. This document was created using LATEX and Sweave (which is really an R package). There are some huge advantages to a workflow like this, relating to a topic called reproducible research. Here’s my thought: pay your dues now, reap the benefits later. Don’t trust me on everything, but trust me on this. A sister document was created using R Markdown and the markdown package, and this is also acceptable. Microsoft Office is not. So, in today’s class I’ll show you how I produced these documents and I’ll give you the required files. I recommend you figure out how to use LATEX on your own computer. You already have Sweave, because it comes with R.
    [Show full text]
  • System Calls and I/O
    System Calls and I/O CS 241 January 27, 2012 Copyright ©: University of Illinois CS 241 Staff 1 This lecture Goals Get you familiar with necessary basic system & I/O calls to do programming Things covered in this lecture Basic file system calls I/O calls Signals Note: we will come back later to discuss the above things at the concept level Copyright ©: University of Illinois CS 241 Staff 2 System Calls versus Function Calls? Copyright ©: University of Illinois CS 241 Staff 3 System Calls versus Function Calls Function Call Process fnCall() Caller and callee are in the same Process - Same user - Same “domain of trust” Copyright ©: University of Illinois CS 241 Staff 4 System Calls versus Function Calls Function Call System Call Process Process fnCall() sysCall() OS Caller and callee are in the same Process - Same user - OS is trusted; user is not. - Same “domain of trust” - OS has super-privileges; user does not - Must take measures to prevent abuse Copyright ©: University of Illinois CS 241 Staff 5 System Calls System Calls A request to the operating system to perform some activity System calls are expensive The system needs to perform many things before executing a system call The computer (hardware) saves its state The OS code takes control of the CPU, privileges are updated. The OS examines the call parameters The OS performs the requested function The OS saves its state (and call results) The OS returns control of the CPU to the caller Copyright ©: University of Illinois CS 241 Staff 6 Steps for Making a System Call
    [Show full text]
  • Ext4 File System and Crash Consistency
    1 Ext4 file system and crash consistency Changwoo Min 2 Summary of last lectures • Tools: building, exploring, and debugging Linux kernel • Core kernel infrastructure • Process management & scheduling • Interrupt & interrupt handler • Kernel synchronization • Memory management • Virtual file system • Page cache and page fault 3 Today: ext4 file system and crash consistency • File system in Linux kernel • Design considerations of a file system • History of file system • On-disk structure of Ext4 • File operations • Crash consistency 4 File system in Linux kernel User space application (ex: cp) User-space Syscalls: open, read, write, etc. Kernel-space VFS: Virtual File System Filesystems ext4 FAT32 JFFS2 Block layer Hardware Embedded Hard disk USB drive flash 5 What is a file system fundamentally? int main(int argc, char *argv[]) { int fd; char buffer[4096]; struct stat_buf; DIR *dir; struct dirent *entry; /* 1. Path name -> inode mapping */ fd = open("/home/lkp/hello.c" , O_RDONLY); /* 2. File offset -> disk block address mapping */ pread(fd, buffer, sizeof(buffer), 0); /* 3. File meta data operation */ fstat(fd, &stat_buf); printf("file size = %d\n", stat_buf.st_size); /* 4. Directory operation */ dir = opendir("/home"); entry = readdir(dir); printf("dir = %s\n", entry->d_name); return 0; } 6 Why do we care EXT4 file system? • Most widely-deployed file system • Default file system of major Linux distributions • File system used in Google data center • Default file system of Android kernel • Follows the traditional file system design 7 History of file system design 8 UFS (Unix File System) • The original UNIX file system • Design by Dennis Ritche and Ken Thompson (1974) • The first Linux file system (ext) and Minix FS has a similar layout 9 UFS (Unix File System) • Performance problem of UFS (and the first Linux file system) • Especially, long seek time between an inode and data block 10 FFS (Fast File System) • The file system of BSD UNIX • Designed by Marshall Kirk McKusick, et al.
    [Show full text]
  • Cygwin User's Guide
    Cygwin User’s Guide Cygwin User’s Guide ii Copyright © Cygwin authors Permission is granted to make and distribute verbatim copies of this documentation provided the copyright notice and this per- mission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this documentation under the conditions for verbatim copying, provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this documentation into another language, under the above conditions for modified versions, except that this permission notice may be stated in a translation approved by the Free Software Foundation. Cygwin User’s Guide iii Contents 1 Cygwin Overview 1 1.1 What is it? . .1 1.2 Quick Start Guide for those more experienced with Windows . .1 1.3 Quick Start Guide for those more experienced with UNIX . .1 1.4 Are the Cygwin tools free software? . .2 1.5 A brief history of the Cygwin project . .2 1.6 Highlights of Cygwin Functionality . .3 1.6.1 Introduction . .3 1.6.2 Permissions and Security . .3 1.6.3 File Access . .3 1.6.4 Text Mode vs. Binary Mode . .4 1.6.5 ANSI C Library . .4 1.6.6 Process Creation . .5 1.6.6.1 Problems with process creation . .5 1.6.7 Signals . .6 1.6.8 Sockets . .6 1.6.9 Select . .7 1.7 What’s new and what changed in Cygwin . .7 1.7.1 What’s new and what changed in 3.2 .
    [Show full text]
  • 11.7 the Windows 2000 File System
    830 CASE STUDY 2: WINDOWS 2000 CHAP. 11 11.7 THE WINDOWS 2000 FILE SYSTEM Windows 2000 supports several file systems, the most important of which are FAT-16, FAT-32, and NTFS (NT File System). FAT-16 is the old MS-DOS file system. It uses 16-bit disk addresses, which limits it to disk partitions no larger than 2 GB. FAT-32 uses 32-bit disk addresses and supports disk partitions up to 2 TB. NTFS is a new file system developed specifically for Windows NT and car- ried over to Windows 2000. It uses 64-bit disk addresses and can (theoretically) support disk partitions up to 264 bytes, although other considerations limit it to smaller sizes. Windows 2000 also supports read-only file systems for CD-ROMs and DVDs. It is possible (even common) to have the same running system have access to multiple file system types available at the same time. In this chapter we will treat the NTFS file system because it is a modern file system unencumbered by the need to be fully compatible with the MS-DOS file system, which was based on the CP/M file system designed for 8-inch floppy disks more than 20 years ago. Times have changed and 8-inch floppy disks are not quite state of the art any more. Neither are their file systems. Also, NTFS differs both in user interface and implementation in a number of ways from the UNIX file system, which makes it a good second example to study. NTFS is a large and complex system and space limitations prevent us from covering all of its features, but the material presented below should give a reasonable impression of it.
    [Show full text]
  • Lab #6: Stat Overview Stat
    February 17, 2017 CSC 357 1 Lab #6: Stat Overview The purpose of this lab is for you to retrieve from the filesystem information pertaining to specified files. You will use portions of this lab in Assignment #4, so be sure to write code that can be reused. stat Write a simplified version of the stat utility available on some Unix distributions. This program should take any number of file names as command-line arguments and output information pertaining to each file as described below (you should use the stat system call). The output from your program should look as follows: File: ‘Makefile’ Type: Regular File Size: 214 Inode: 4702722 Links: 1 Access: -rw------- The stat system call provides more information about a file, but this lab only requires the above. The format of each field follows: • File: the name of the file being examined. • Type: the type of file output as “Regular File”, “Directory”, “Character Device”, “Block Device”, “FIFO”, or “Symbolic Link” • Size: the number of bytes in the file. • Inode: the file’s inode. • Links: the number of links to the file. • Access: the access permissions for the file. This field is the most involved since the output string can take many forms. The first bit of the access permissions denotes the type (similar to the second field above). The valid characters for the first bit are: b – Block special file. c – Character special file. d – Directory. l – Symbolic link. p – FIFO. - – Regular file. The remaining bits denote the read, write and execute permissions for the user, group, and others.
    [Show full text]
  • How UNIX Organizes and Accesses Files on Disk Why File Systems
    UNIX File Systems How UNIX Organizes and Accesses Files on Disk Why File Systems • File system is a service which supports an abstract representation of the secondary storage to the OS • A file system organizes data logically for random access by the OS. • A virtual file system provides the interface between the data representation by the kernel to the user process and the data presentation to the kernel in memory. The file and directory system cache. • Because of the performance disparity between disk and CPU/memory, file system performance is the paramount issue for any OS Main memory vs. Secondary storage • Small (MB/GB) Large (GB/TB) • Expensive Cheap -2 -3 • Fast (10-6/10-7 sec) Slow (10 /10 sec) • Volatile Persistent Cannot be directly accessed • Directly accessible by CPU by CPU – Interface: (virtual) memory – Data should be first address brought into the main memory Secondary storage (disk) • A number of disks directly attached to the computer • Network attached disks accessible through a fast network - Storage Area Network (SAN) • Simple disks (IDE, SATA) have a described disk geometry. Sector size is the minimum read/write unit of data (usually 512Bytes) – Access: (#surface, #track, #sector) • Smart disks (SCSI, SAN, NAS) hide the internal disk layout using a controller type function – Access: (#sector) • Moving arm assembly (Seek) is expensive – Sequential access is x100 times faster than the random access Internal disk structure • Disk structure User Process Accessing Data • Given the file name. Get to the file’s FCB using the file system catalog (Open, Close, Set_Attribute) • The catalog maps a file name to the FCB – Checks permissions • file_handle=open(file_name): – search the catalog and bring FCB into the memory – UNIX: in-memory FCB: in-core i-node • Use the FCB to get to the desired offset within the file data: (CREATE, DELETE, SEEK, TRUNCATE) • close(file_handle): release FCB from memory Catalog Organization (Directories) • In UNIX, special files (not special device files) called directories contain information about other files.
    [Show full text]
  • File Systems
    File Systems Profs. Bracy and Van Renesse based on slides by Prof. Sirer Storing Information • Applications could store information in the process address space • Why is this a bad idea? – Size is limited to size of virtual address space – The data is lost when the application terminates • Even when computer doesn’t crash! – Multiple process might want to access the same data File Systems • 3 criteria for long-term information storage: 1. Able to store very large amount of information 2. Information must survive the processes using it 3. Provide concurrent access to multiple processes • Solution: – Store information on disks in units called files – Files are persistent, only owner can delete it – Files are managed by the OS File Systems: How the OS manages files! File Naming • Motivation: Files abstract information stored on disk – You do not need to remember block, sector, … – We have human readable names • How does it work? – Process creates a file, and gives it a name • Other processes can access the file by that name – Naming conventions are OS dependent • Usually names as long as 255 characters is allowed • Windows names not case sensitive, UNIX family is File Extensions • Name divided into 2 parts: Name+Extension • On UNIX, extensions are not enforced by OS – Some applications might insist upon them • Think: .c, .h, .o, .s, etc. for C compiler • Windows attaches meaning to extensions – Tries to associate applications to file extensions File Access • Sequential access – read all bytes/records from the beginning – particularly convenient for magnetic tape • Random access – bytes/records read in any order – essential for database systems File Attributes • File-specific info maintained by the OS – File size, modification date, creation time, etc.
    [Show full text]
  • Secure Untrusted Data Repository (SUNDR)
    Secure Untrusted Data Repository (SUNDR) Jinyuan Li, Maxwell Krohn,∗ David Mazieres,` and Dennis Shasha NYU Department of Computer Science Abstract for over 20,000 different software packages. Many of these packages are bundled with various operating sys- SUNDR is a network file system designed to store data tem distributions, often without a meaningful audit. By securely on untrusted servers. SUNDR lets clients de- compromising sourceforge, an attacker can therefore in- tect any attempts at unauthorized file modification by troduce subtle vulnerabilities in software that may even- malicious server operators or users. SUNDR’s protocol tually run on thousands or even millions of machines. achieves a property called fork consistency, which guar- Such concerns are no mere academic exercise. For ex- antees that clients can detect any integrity or consistency ample, the Debian GNU/Linux development cluster was failures as long as they see each other’s file modifications. compromised in 2003 [2]. An unauthorized attacker used An implementation is described that performs compara- a sniffed password and a kernel vulnerability to gain su- bly with NFS (sometimes better and sometimes worse), peruser access to Debian’s primary CVS and Web servers. while offering significantly stronger security. After detecting the break-in, administrators were forced to freeze development for several days, as they employed manual and ad-hoc sanity checks to assess the extent of 1 Introduction the damage. Similar attacks have also succeeded against Apache [1], Gnome [32], and other popular projects. SUNDR is a network file system that addresses a long- Rather than hope for invulnerable servers, we have de- standing tension between data integrity and accessibility.
    [Show full text]
  • File System Layout
    File Systems Main Points • File layout • Directory layout • Reliability/durability Named Data in a File System index !le name directory !le number structure storage o"set o"set block Last Time: File System Design Constraints • For small files: – Small blocks for storage efficiency – Files used together should be stored together • For large files: – ConCguous allocaon for sequenCal access – Efficient lookup for random access • May not know at file creaon – Whether file will become small or large File System Design Opons FAT FFS NTFS Index Linked list Tree Tree structure (fixed, asym) (dynamic) granularity block block extent free space FAT array Bitmap Bitmap allocaon (fixed (file) locaon) Locality defragmentaon Block groups Extents + reserve Best fit space defrag MicrosoS File Allocaon Table (FAT) • Linked list index structure – Simple, easy to implement – SCll widely used (e.g., thumb drives) • File table: – Linear map of all blocks on disk – Each file a linked list of blocks FAT MFT Data Blocks 0 1 2 3 !le 9 block 3 4 5 6 7 8 9 !le 9 block 0 10 !le 9 block 1 11 !le 9 block 2 12 !le 12 block 0 13 14 15 16 !le 12 block 1 17 18 !le 9 block 4 19 20 FAT • Pros: – Easy to find free block – Easy to append to a file – Easy to delete a file • Cons: – Small file access is slow – Random access is very slow – Fragmentaon • File blocks for a given file may be scaered • Files in the same directory may be scaered • Problem becomes worse as disk fills Berkeley UNIX FFS (Fast File System) • inode table – Analogous to FAT table • inode – Metadata • File owner, access permissions,
    [Show full text]
  • Stat System Administration Guide Updated - November 2018 Software Version - 6.2.0 Contents
    Quest® Stat® 6.2.0 System Administration Guide © 2018 Quest Software Inc. ALL RIGHTS RESERVED. This guide contains proprietary information protected by copyright. The software described in this guide is furnished under a software license or nondisclosure agreement. This software may be used or copied only in accordance with the terms of the applicable agreement. No part of this guide may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording for any purpose other than the purchaser’s personal use without the written permission of Quest Software Inc. The information in this document is provided in connection with Quest Software products. No license, express or implied, by estoppel or otherwise, to any intellectual property right is granted by this document or in connection with the sale of Quest Software products. EXCEPT AS SET FORTH IN THE TERMS AND CONDITIONS AS SPECIFIED IN THE LICENSE AGREEMENT FOR THIS PRODUCT, QUEST SOFTWARE ASSUMES NO LIABILITY WHATSOEVER AND DISCLAIMS ANY EXPRESS, IMPLIED OR STATUTORY WARRANTY RELATING TO ITS PRODUCTS INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. IN NO EVENT SHALL QUEST SOFTWARE BE LIABLE FOR ANY DIRECT, INDIRECT, CONSEQUENTIAL, PUNITIVE, SPECIAL OR INCIDENTAL DAMAGES (INCLUDING, WITHOUT LIMITATION, DAMAGES FOR LOSS OF PROFITS, BUSINESS INTERRUPTION OR LOSS OF INFORMATION) ARISING OUT OF THE USE OR INABILITY TO USE THIS DOCUMENT, EVEN IF QUEST SOFTWARE HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Quest Software makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice.
    [Show full text]
  • Apple File System Reference
    Apple File System Reference Developer Contents About Apple File System 7 General-Purpose Types 9 paddr_t .................................................. 9 prange_t ................................................. 9 uuid_t ................................................... 9 Objects 10 obj_phys_t ................................................ 10 Supporting Data Types ........................................... 11 Object Identifier Constants ......................................... 12 Object Type Masks ............................................. 13 Object Types ................................................ 14 Object Type Flags .............................................. 20 EFI Jumpstart 22 Booting from an Apple File System Partition ................................. 22 nx_efi_jumpstart_t ........................................... 24 Partition UUIDs ............................................... 25 Container 26 Mounting an Apple File System Partition ................................... 26 nx_superblock_t ............................................. 27 Container Flags ............................................... 36 Optional Container Feature Flags ...................................... 37 Read-Only Compatible Container Feature Flags ............................... 38 Incompatible Container Feature Flags .................................... 38 Block and Container Sizes .......................................... 39 nx_counter_id_t ............................................. 39 checkpoint_mapping_t ........................................
    [Show full text]