DOCSLIB.ORG

Forensic Analysis of the Resilient File System (Refs) Version 3.4

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Forensic Analysis of the Resilient File System (Refs) Version 3.4 Forensic Analysis of the Resilient File System (ReFS) Version 3.4 Paul Pradea, Tobias Großa,∗, Andreas Dewaldb,a,∗ aFriedrich-Alexander University Erlangen-N¨urnberg, Germany bERNW Research GmbH, Heidelberg, Germany Abstract ReFS is a modern file system that is developed by Microsoft and its internal structures and behavior is not officially documented. Even so there exist some analysis efforts in deciphering its data structures, some of these findings have yet become deprecated and cannot be applied to current ReFS versions anymore. In this work, general concepts and internal structures found in ReFS are examined and documented. Based on the structures and the processes by which they are modified, approaches to recover (deleted) files from ReFS formatted file systems are shown. We also evaluated our implementation and the allocation strategy of ReFS with respect to accuracy, runtime and the ability to recover older file states. Keywords: Digital forensics, Data recovery, File systems, ReFS 1. Introduction Sinofsky (2012) explains key goals as well as features like checksums for meta- and content-data as well as the Storage media analysis is a common task in the field of Copy-On-Write (COW) mechanism that are provided by digital forensic, when PCs or mobile devices get analyzed. ReFS. He also mentions a generic key-value interface which Investigators have to rely on the proper functioning of their is used by ReFS to manage on-disk structures. tools to provide them with correct interpretation of traces. In a working report, Green (2013) analyzed the internal File systems have to be interpreted and presented when structures of ReFS and created an overview of identified analyzing storage media, doing this manually is unfeasible. structures. This report skipped how the internal key-value From this situation emerges the need for digital forensic structure of ReFS works. He also looked into the recovery of tools to ideally support all of the file systems that are cur- deleted items, but only describes the recycle bin mechanism rently in use and may be encountered in a forensic analysis. of the windows file explorer which is not specific to ReFS. Limitations of classical file systems such as low perfor- Another unofficial draft of structures found under ReFS mance, limited capacity or unsuitability for SSD drives led is provided by Metz (2013). This work strongly focuses on to the development of new filesystems like APFS or ReFS. the low-level presentation of how data structures in ReFS These new filesystems have to be supported in open source are composed and was the first to vaguely describe the forensic tools and documentation. Transparency in forensic key-value store. The author implemented a library which processes and tools is important when digital evidence is is based on his findings. used in severe cases. That is even more important when Georges (2018) aimed to develop a tool which outputs filesystems are proprietary as the above-mentioned ones. results comparable to EnCase. He also described how the al- With this work, we want to provide the forensic commu- location status of clusters is managed. With the developed nity with tools and information to properly analyze ReFS tool, file extraction is possible for ReFS v1.2. partitions. Nordvik et al. (2019) also examined data structures of ReFS. They mainly focused on v1.2 and v3.2 of ReFS. 1.1. Related Work At the end they tested their findings on v3.4, too. For There exists related work that we show in the following v3.2 they came to the conclusion that the versions did not which analyzed ReFS before, but they looked into versions differ much from v1.2 and that \the structures are almost 1.1 and 1.2. Some core concepts still exist in the latest identical". In our work we come to the conclusion that version 3.4 but also major changes were applied between between v3.4 and v1.2 many data structures were added, these versions, which draws older work incompatible to deprecated or changed. We found also new functionality newer versions of ReFS. like virtual addresses which have to be taken into account when extracting data from the disk. In contrast to their work, we discovered more details and also investigate how ∗Corresponding author Email addresses: [email protected] (Tobias Groß), the Copy-On-Write mechanism of ReFS is implemented [email protected] (Andreas Dewald) and propose strategies to recover old versions of files. Preprint submitted to DFRWS EU December 13, 2019 1.2. Our Contribution Table Identifier Table Name In this work, we analyzed the proprietary Microsoft 0x2 Object ID Table Windows Resilient File System (ReFS) version 3.4 and 0x21 Medium Allocator Table contribute the following: 0x20 Container Allocator Table • We analyzed the internal structures and mechanics 0x1 Schema Table of ReFS v3.4 and documented them in a technical 0x3 Parent Child Table report. (Prade et al. (2019)) 0x4 Object ID Table, duplicate • We extended The Sleuth Kit from Carrier to support 0x5 Block Reference Count Table ReFS. 0xb Container Table • We propose strategies for recovering deleted files. 0xc Container Table, duplicate • We implemented a page carver which allows the re- 0x6 Schema Table, duplicate construction of deleted files and older file states. 0xe Container Index Table • We evaluated the correctness of our implementation 0xf Integrity State Table with different ReFS partitions. 0x22 Small Allocator Table • We analyzed the allocation strategy of ReFS v3.4 which affects the recoverability of older file states and Table 1: Tables referenced by the checkpoint structure compared the findings with our carver. 2. Background 3.1. Checkpoint ReFS partitions have 2 checkpoint structures which are The Sleuth Kit. The Sleuth Kit (TSK) is an open-source written alternately, to have at least one valid checkpoint filesystem forensic tool. It was developed with high porta- in case of a crash. The checkpoint of a file system is the bility and extensibility in mind (Altheide and Carvey, 2011, first structure that holds the current clock values, which p. 42). The highly extensible design of TSK allows devel- indicates the latest checkpoint structure. Additionally, the opers to extend its functionality as well as the types of file checkpoint also contains the current log sequence number systems it supports. TSK is structured into multiple layers (LSN) which identifies the last entry that was written into of abstraction that map how data is stored on storage me- the redo log. Since ReFS stores changes to the file system dia. The File System Layer is of most importance within in the memory and writes them at a later point as a batch, this work, as this is the abstraction where file systems such the system may crash in this time window. A system crash as FAT, NTFS and also ReFS are settled. reverts the system to its last valid state and would discard all changes executed in the meantime. However, every Copy-On-Write. Copy-On-Write (COW) is an update pol- transaction that was successfully performed and is part icy that may be used to alter data on a storage medium. A of the batch is also written to a sequential log file that is COW update policy makes sure that data is never updated discussed in our report. To know from where to start with in place. Whenever the content of a block should be altered, the redo operations, it is essential to save an identifier for the block is read into memory, modified and its content the last transaction that was part of the current checkpoint. is written to an alternate location on the storage medium. The most important structures found in the checkpoint When the system crashes while a block is updated through are the table references. For the sake of thoroughness, a COW policy, the old state of the data remains untouched table 1 presents an overview of all tables referenced by the and still persists. COW offers a simple strategy to enforce checkpoint along with their table identifiers. atomicity in write operations and to ensure the integrity of data structures (Rodeh et al., 2013, p. 15). 3.2. Container Table Internally a ReFS volume is separated into multiple 3. ReFS Internal Structure equally sized bands or containers. The size of a single band is relatively large at around 64 MiB or 256 MiB. We analyzed the structure of ReFS and classified ident- The Container Table provides detailed information on that fied structures into the categories File System, Content, managed memory regions. It tracks how many clusters File Name, Metadata and Application introduced by Car- within a band are used and additionally collects statistics rier (2005). Detailed structure description of ReFS which about the usage of data and access times within that band. are important for forensic analyses can be found in our tech- Tipton (2015) argues that the introduction of Container nical report (Prade et al. (2019)). In this work we describe Tables was important to treat multi-tiered storage systems only the structures important for enumerating and recov- more efficiently. In a multi-tiered storage system, it is ering files and folders. The ordering corresponds to the common to have different types of storage media that offer occurrence when starting interpreting an ReFS partition different reading and writing characteristics. Some storage at the boot sector. media such as flash memory allow performing random 2 access faster than traditional hard disks, which are more The Object ID Table additionally stores meta-information suitable to perform sequential operations. about the tables that it references. It stores the addresses In a multi-tiered storage system, data needs to be reor- and the checksums of the tables it references, as well as ganized according to its characteristics.
Load more

Recommended publications
  • File Protection – Using Rsync Whitepaper
    File Protection – Using Rsync Whitepaper Contents 1. Introduction ..................................................................................................................................... 2 Documentation .................................................................................................................................................................. 2 Licensing ............................................................................................................................................................................... 2 Terminology ........................................................................................................................................................................ 2 2. Rsync technology ............................................................................................................................ 3 Overview ............................................................................................................................................................................... 3 Implementation ................................................................................................................................................................. 3 3. Rsync data hosts .............................................................................................................................. 5 Third Party data host ......................................................................................................................................................
    [Show full text]
  • Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected]
    Nova Southeastern University NSUWorks CEC Theses and Dissertations College of Engineering and Computing 2017 Enhancing the Accuracy of Synthetic File System Benchmarks Salam Farhat Nova Southeastern University, [email protected] This document is a product of extensive research conducted at the Nova Southeastern University College of Engineering and Computing. For more information on research and degree programs at the NSU College of Engineering and Computing, please click here. Follow this and additional works at: https://nsuworks.nova.edu/gscis_etd Part of the Computer Sciences Commons Share Feedback About This Item NSUWorks Citation Salam Farhat. 2017. Enhancing the Accuracy of Synthetic File System Benchmarks. Doctoral dissertation. Nova Southeastern University. Retrieved from NSUWorks, College of Engineering and Computing. (1003) https://nsuworks.nova.edu/gscis_etd/1003. This Dissertation is brought to you by the College of Engineering and Computing at NSUWorks. It has been accepted for inclusion in CEC Theses and Dissertations by an authorized administrator of NSUWorks. For more information, please contact [email protected]. Enhancing the Accuracy of Synthetic File System Benchmarks by Salam Farhat A dissertation submitted in partial fulfillment of the requirements for the degree of Doctor in Philosophy in Computer Science College of Engineering and Computing Nova Southeastern University 2017 We hereby certify that this dissertation, submitted by Salam Farhat, conforms to acceptable standards and is fully adequate in scope and quality to fulfill the dissertation requirements for the degree of Doctor of Philosophy. _____________________________________________ ________________ Gregory E. Simco, Ph.D. Date Chairperson of Dissertation Committee _____________________________________________ ________________ Sumitra Mukherjee, Ph.D. Date Dissertation Committee Member _____________________________________________ ________________ Francisco J.
    [Show full text]
  • Cyber502x Computer Forensics
    CYBER502x Computer Forensics Unit 5: Windows File Systems CYBER 502x Computer Forensics | Yin Pan Basic concepts in Windows • Clusters • The basic storage unit of a disk • The piece of storage that an operating system can actually place data into • Different disk formats have different cluster sizes • Slack space • If they are not filled up-which, the last one almost never is –this excess capacity in the last cluster Old Data Old New Data Overwrites CYBER 502x Computer Forensics | Yin Pan What does a file system do? • Make a structure for an operating system to stores files • For you to access them by name, location, date, or other characteristic. • File System Format • The process of turning a partition into a recognizable file system CYBER 502x Computer Forensics | Yin Pan Windows File Systems • File Allocation Table (FAT) • FAT 12 • FAT 16 • FAT 32 • exFAT • NTFS, a file system for Windows NT/2K • NTFS4 • NTFS5 • ReFS, a file system for Windows Server 2012 CYBER 502x Computer Forensics | Yin Pan FAT File System Structure • The boot record • The File Allocation Tables • The root directory • The data area CYBER 502x Computer Forensics | Yin Pan Boot record • The first sector of a FAT12 or FAT16 volume • The first 3 sectors of a FAT 32 volume • Defines the volume, the offset of the other three areas • Contains boot program if it is bootable CYBER 502x Computer Forensics | Yin Pan FAT (File Allocation Table ) • A lookup table to see which cluster comes next • File Allocation Table for FAT 16 • One entry is 16 bits representing one cluster • Each entry can be • The cluster contains defective sectors (FFF7) • the address of the next cluster in the same file (A8F7) • a special value for "not allocated" (0000) • a special value for "this is the last cluster in the chain“ (FFFF) CYBER 502x Computer Forensics | Yin Pan Directory entry structure • Starting from the root directory.
    [Show full text]
  • [13주차] Sysfs and Procfs
    1 7 Computer Core Practice1: Operating System Week13. sysfs and procfs Jhuyeong Jhin and Injung Hwang Embedded Software Lab. Embedded Software Lab. 2 sysfs 7 • A pseudo file system provided by the Linux kernel. • sysfs exports information about various kernel subsystems, HW devices, and associated device drivers to user space through virtual files. • The mount point of sysfs is usually /sys. • sysfs abstrains devices or kernel subsystems as a kobject. Embedded Software Lab. 3 How to create a file in /sys 7 1. Create and add kobject to the sysfs 2. Declare a variable and struct kobj_attribute – When you declare the kobj_attribute, you should implement the functions “show” and “store” for reading and writing from/to the variable. – One variable is one attribute 3. Create a directory in the sysfs – The directory have attributes as files • When the creation of the directory is completed, the directory and files(attributes) appear in /sys. • Reference: ${KERNEL_SRC_DIR}/include/linux/sysfs.h ${KERNEL_SRC_DIR}/fs/sysfs/* • Example : ${KERNEL_SRC_DIR}/kernel/ksysfs.c Embedded Software Lab. 4 procfs 7 • A special filesystem in Unix-like operating systems. • procfs presents information about processes and other system information in a hierarchical file-like structure. • Typically, it is mapped to a mount point named /proc at boot time. • procfs acts as an interface to internal data structures in the kernel. The process IDs of all processes in the system • Kernel provides a set of functions which are designed to make the operations for the file in /proc : “seq_file interface”. – We will create a file in procfs and print some data from data structure by using this interface.
    [Show full text]
  • Refs: Is It a Game Changer? Presented By: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam
    Technical Brief ReFS: Is It a Game Changer? Presented by: Rick Vanover, Director, Technical Product Marketing & Evangelism, Veeam Sponsored by ReFS: Is It a Game Changer? OVERVIEW Backing up data is more important than ever, as data centers store larger volumes of information and organizations face various threats such as ransomware and other digital risks. Microsoft’s Resilient File System or ReFS offers a more robust solution than the old NT File System. In fact, Microsoft has stated that ReFS is the preferred data volume for Windows Server 2016. ReFS is an ideal solution for backup storage. By utilizing the ReFS BlockClone API, Veeam has developed Fast Clone, a fast, efficient storage backup solution. This solution offers organizations peace of mind through a more advanced approach to synthetic full backups. CONTEXT Rick Vanover discussed Microsoft’s Resilient File System (ReFS) and described how Veeam leverages this technology for its Fast Clone backup functionality. KEY TAKEAWAYS Resilient File System is a Microsoft storage technology that can transform the data center. Resilient File System or ReFS is a valuable Microsoft storage technology for data centers. Some of the key differences between ReFS and the NT File System (NTFS) are: ReFS provides many of the same limits as NTFS, but supports a larger maximum volume size. ReFS and NTFS support the same maximum file name length, maximum path name length, and maximum file size. However, ReFS can handle a maximum volume size of 4.7 zettabytes, compared to NTFS which can only support 256 terabytes. The most common functions are available on both ReFS and NTFS.
    [Show full text]
  • Oracle® Linux 7 Managing File Systems
    Oracle® Linux 7 Managing File Systems F32760-07 August 2021 Oracle Legal Notices Copyright © 2020, 2021, Oracle and/or its affiliates. This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, the use, reproduction, duplication, release, display, disclosure, modification, preparation of derivative works, and/or adaptation of i) Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs), ii) Oracle computer documentation and/or iii) other Oracle data, is subject to the rights and limitations specified in the license contained in the applicable contract.
    [Show full text]
  • File Management Virtual File System: Interface, Data Structures
    File management Virtual file system: interface, data structures Table of contents • Virtual File System (VFS) • File system interface Motto – Creating and opening a file – Reading from a file Everything is a file – Writing to a file – Closing a file • VFS data structures – Process data structures with file information – Structure fs_struct – Structure files_struct – Structure file – Inode – Superblock • Pipe vs FIFO 2 Virtual File System (VFS) VFS (source: Tizen Wiki) 3 Virtual File System (VFS) Linux can support many different (formats of) file systems. (How many?) The virtual file system uses a unified interface when accessing data in various formats, so that from the user level adding support for the new data format is relatively simple. This concept allows implementing support for data formats – saved on physical media (Ext2, Ext3, Ext4 from Linux, VFAT, NTFS from Microsoft), – available via network (like NFS), – dynamically created at the user's request (like /proc). This unified interface is fully compatible with the Unix-specific file model, making it easier to implement native Linux file systems. 4 File System Interface In Linux, processes refer to files using a well-defined set of system functions: – functions that support existing files: open(), read(), write(), lseek() and close(), – functions for creating new files: creat(), – functions used when implementing pipes: pipe() i dup(). The first step that the process must take to access the data of an existing file is to call the open() function. If successful, it passes the file descriptor to the process, which it can use to perform other operations on the file, such as reading (read()) and writing (write()).
    [Show full text]
  • Filesystem Considerations for Embedded Devices ELC2015 03/25/15
    Filesystem considerations for embedded devices ELC2015 03/25/15 Tristan Lelong Senior embedded software engineer Filesystem considerations ABSTRACT The goal of this presentation is to answer a question asked by several customers: which filesystem should you use within your embedded design’s eMMC/SDCard? These storage devices use a standard block interface, compatible with traditional filesystems, but constraints are not those of desktop PC environments. EXT2/3/4, BTRFS, F2FS are the first of many solutions which come to mind, but how do they all compare? Typical queries include performance, longevity, tools availability, support, and power loss robustness. This presentation will not dive into implementation details but will instead summarize provided answers with the help of various figures and meaningful test results. 2 TABLE OF CONTENTS 1. Introduction 2. Block devices 3. Available filesystems 4. Performances 5. Tools 6. Reliability 7. Conclusion Filesystem considerations ABOUT THE AUTHOR • Tristan Lelong • Embedded software engineer @ Adeneo Embedded • French, living in the Pacific northwest • Embedded software, free software, and Linux kernel enthusiast. 4 Introduction Filesystem considerations Introduction INTRODUCTION More and more embedded designs rely on smart memory chips rather than bare NAND or NOR. This presentation will start by describing: • Some context to help understand the differences between NAND and MMC • Some typical requirements found in embedded devices designs • Potential filesystems to use on MMC devices 6 Filesystem considerations Introduction INTRODUCTION Focus will then move to block filesystems. How they are supported, what feature do they advertise. To help understand how they compare, we will present some benchmarks and comparisons regarding: • Tools • Reliability • Performances 7 Block devices Filesystem considerations Block devices MMC, EMMC, SD CARD Vocabulary: • MMC: MultiMediaCard is a memory card unveiled in 1997 by SanDisk and Siemens based on NAND flash memory.
    [Show full text]
  • [MS-FSCC]: File System Control Codes
    [MS-FSCC]: File System Control Codes This topic lists the Errata found in the MS-FSCC document since it was last RSS published. Since this topic is updated frequently, we recommend that you subscribe to these RSS or Atom feeds to receive update notifications. Atom Errata are subject to the same terms as the Open Specifications documentation referenced. Errata below are for Protocol Document Version V45.0 – 2018/09/12. Errata Published* Description 2019/08/05 In Section 2.3.42, FSCTL_QUERY_FILE_REGIONS Reply, the length of the Region field has been changed from 24 bytes to variable. 2019/08/05 In Section 2.3.41, FSCTL_QUERY_FILE_REGIONS Request, a new Reserved field has been added to the end of the data element. Added: Reserved (4 bytes): A 32-bit unsigned integer that is reserved. This field SHOULD be 0x00000000 and MUST be ignored. 2019/08/05 In Section 2.3.41, FSCTL_QUERY_FILE_REGIONS Request, new product behavior notes have been added to FILE_REGION_USAGE_VALID_CACHED_DATA and FILE_REGION_USAGE_VALID_NONCACHED_DATA. Added: <30> Section 2.3.41: This region usage flag can only be specified for volumes using the NTFS file system. <31> Section 2.3.41: This region usage flag can only be specified for volumes using the ReFS file system. In Section 2.3.42.1, FILE_REGION_INFO, the DesiredUsage field has been changed from: DesiredUsage (4 bytes): A 32-bit unsigned integer that indicates the usage for the given region of the file. The valid values are defined in section 2.3.41. Changed to: DesiredUsage (4 bytes): A 32-bit unsigned integer that indicates the usage for the given region of the file.
    [Show full text]
  • Virtual File System on Linux Lsudhanshoo Maroo(00D05001) Lvirender Kashyap (00D05011) Virtual File System on Linux
    Virtual File System on Linux lSudhanshoo Maroo(00D05001) lVirender Kashyap (00D05011) Virtual File System on Linux. What is it ? VFS is a kernel software layer that handles all system calls related to file systems. Its main strength is providing a common interface to several kinds of file systems. What's LinuxVFS's key idea? For each read, write or other function called, the kernel substitutes the actual function that supports a native Linux file system, for example the NTFS. File systems supported by Linux VFS - disk based file systems like ext3, VFAT - network file systems - other special file systems like /proc VFS File Model Superblock object Ø Stores information concerning a mounted file system. Ø Holds things like device, blocksize, dirty flags, list of dirty inodes etc. Ø Super operations -> like read/write/delete/clear inode etc. Ø Gives pointer to the root inode of this FS Ø Superblock manipulators: mount/umount File object q Stores information about the interaction between an open file and a process. q File pointer points to the current position in the file from which the next operation will take place. VFS File Model inode object Ø stores general information about a specific file. Ø Linux keeps a cache of active and recently used inodes. Ø All inodes within a file system are accessed by file-name. Ø Linux's VFS layer maintains a cache of currently active and recently used names, called dcache dcache Ø structured in memory as a tree. Ø each entry or node in tree (dentry) points to an inode. Ø it is not a complete copy of a file tree Note : If any node of the file tree is in the cache then every ancestor of that node is also in the cache.
    [Show full text]
  • Simple File Manager for Amazon EFS Implementation Guide Simple File Manager for Amazon EFS Implementation Guide
    Simple File Manager for Amazon EFS Implementation Guide Simple File Manager for Amazon EFS Implementation Guide Simple File Manager for Amazon EFS: Implementation Guide Copyright © Amazon Web Services, Inc. and/or its affiliates. All rights reserved. Amazon's trademarks and trade dress may not be used in connection with any product or service that is not Amazon's, in any manner that is likely to cause confusion among customers, or in any manner that disparages or discredits Amazon. All other trademarks not owned by Amazon are the property of their respective owners, who may or may not be affiliated with, connected to, or sponsored by Amazon. Simple File Manager for Amazon EFS Implementation Guide Table of Contents Welcome ........................................................................................................................................... 1 Cost .................................................................................................................................................. 2 Architecture overview ......................................................................................................................... 3 Solution components .......................................................................................................................... 4 Web UI ..................................................................................................................................... 4 Security ...........................................................................................................................................
    [Show full text]
  • Operating Systems Lecture #5: File Management
    Operating Systems Lecture #5: File Management Written by David Goodwin based on the lecture series of Dr. Dayou Li and the book Understanding Operating Systems 4thed. by I.M.Flynn and A.McIver McHoes (2006) Department of Computer Science and Technology, University of Bedfordshire. Operating Systems, 2013 25th February 2013 Outline Lecture #5 File Management David Goodwin 1 Introduction University of Bedfordshire 2 Interaction with the file manager Introduction Interaction with the file manager 3 Files Files Physical storage 4 Physical storage allocation allocation Directories 5 Directories File system Access 6 File system Data compression summary 7 Access 8 Data compression 9 summary Operating Systems 46 Lecture #5 File Management David Goodwin University of Bedfordshire Introduction 3 Interaction with the file manager Introduction Files Physical storage allocation Directories File system Access Data compression summary Operating Systems 46 Introduction Lecture #5 File Management David Goodwin University of Bedfordshire Introduction 4 Responsibilities of the file manager Interaction with the file manager 1 Keep track of where each file is stored Files 2 Use a policy that will determine where and how the files will Physical storage be stored, making sure to efficiently use the available storage allocation space and provide efficient access to the files. Directories 3 Allocate each file when a user has been cleared for access to File system it, and then record its use. Access 4 Deallocate the file when the file is to be returned to storage, Data compression and communicate its availability to others who may be summary waiting for it. Operating Systems 46 Definitions Lecture #5 File Management field is a group of related bytes that can be identified by David Goodwin University of the user with a name, type, and size.
    [Show full text]