1. OSes: 10. FileSys Intf. 1 Operating Systems v Objectives –describe the user interface to the file system (files, directories, access) Certificate Program in Software Development CSE-TC and CSIM, AIT September -- November, 2003 10. File System Interface (Ch. 10 S&G)

2. OSes: 10. FileSys Intf. 2 Contents 1.The File Concept 2.Access Methods 3.Directory Structure 4.Protection 5.Consistency Semantics

3. OSes: 10. FileSys Intf. 3 1. The File Concept v The file system provides a uniform logical view of physical storage. v Smallest logical storage unit is the file –usually mapped to storage on a nonvolatile physical device

4. OSes: 10. FileSys Intf. 4 1.1. File Attributes v Name v Type v Location v Size v Protection –access controls for who can read, write, execute the file v Time(s)

5. OSes: 10. FileSys Intf. 5 1.2. File Operations v View a file as an abstract data type –data as bits/bytes/lines/records –operations v Six basic operations: –create, write, read, seek in a file, delete, truncate continued

6. OSes: 10. FileSys Intf. 6 v Requires read and write pointers, or a current-file-position pointer. v Other possible operations: –append, copy, rename –get/set file attributes –etc.

7. OSes: 10. FileSys Intf. 7 1.3. Opening a File  open() finds the file and stores a pointer to it in an open file table (OFT). v I/O operations use the pointer rather than the file name so there is no need to search for the file each time.

8. OSes: 10. FileSys Intf. 8 Multi-user Variation v Several users may have the same file open at the same time. v Use two levels of internal tables: –an OFT per process storing details on the open files of the process u e.g. file pointers, access rights –a system-wide OFT storing process-independent details on the files u location on disk, size, open count, lock(s)

9. OSes: 10. FileSys Intf. 9 Two-level File Tables system OFT process P1 OFT process P2 VUW CS 305 OFT

10. OSes: 10. FileSys Intf. 10 1.4. File Types v Useful so the OS can automatically modify its processing behaviour –e.g. differentiate between source code (open with an editor) and object code (execute) –know that files are ‘related’ e.g. example.c and example.o continued

11. OSes: 10. FileSys Intf. 11 v Approaches: –file name extensions (e.g. Windows) –creator attributes (e.g. Mac) –magic numbers (e.g. UNIX)

12. OSes: 10. FileSys Intf. 12 1.5. File Structures v Most modern OSes support a minimal number of file structures directly –e.g. UNIX sees every file as a sequence of 8-bit bytes v Benefits: –applications have more flexibility –simplifies the OS

13. OSes: 10. FileSys Intf. 13 Internal File Structures v Packing is required to convert between logical records and physical blocks –internal fragmentation will occur Physical blocks Logical records

14. OSes: 10. FileSys Intf. 14 2. Access Methods v 2.1. Sequential Access Fig. 10.3, p.347 beginning current position end rewind read or write

15. OSes: 10. FileSys Intf. 15 2.2. Direct Access v A file is made up of fixed length logical records (a disk model). v Can move quickly to any record location by supplying a relative record number –relative to the current record position –e.g. seek(20); // move to rec. 20 seek(-1); // move to rec. 19 read();

16. OSes: 10. FileSys Intf. 16 2.3. Indexed Access v Make an index file for the file, which contains pointers to various records –improves search time Fig. 10.5, p.349 Adams Arthur Asher Smith : index file Smith, John00723 direct access file

17. OSes: 10. FileSys Intf. 17 2.4. Memory Mapping v Map sections of a file into virtual memory. v Reads and writes to the mapped region act as reads and writes to the file. v Useful way of sharing a file –but requires a mutual exclusion mechanism continued

18. OSes: 10. FileSys Intf. 18 file region Process B virtual memory Memory Mapping Diagram region Process A virtual memory physical memory

19. OSes: 10. FileSys Intf. 19 3. Directory Structure v Partitions (mini-disks, volumes) –provide separate logical spaces on one disk –group several disks into a single logical space v Device directory –holds file information (e.g. name, location, size, type) for all files in that partition

20. OSes: 10. FileSys Intf. 20 Typical Directory Operations v Search v Create a file v Delete a file v List a directory v Remove a file v Traverse all the files –e.g. for making backups

21. OSes: 10. FileSys Intf. 21 Types of Directory Structure v 3.1. Single-level Directory v 3.2. Two-level Directory v 3.3. Tree-structured Directory v 3.4. Acyclic Graph Directory v 3.5. General Graph Directory

22. OSes: 10. FileSys Intf. 22 3.1. Single-level Directory v Easy to support and understand. v Problems start when there are large numbers of files and/or users. Fig. 10.7, p.351 logfoorecs1testdatamailrecs2

23. OSes: 10. FileSys Intf. 23 3.2. Two-level Directory Fig. 10.8, p.352 logfoorecs1testdatamailrecs2 user1user2user3 User File Directory (UFD) Master File Directory (MFD) continued

24. OSes: 10. FileSys Intf. 24 Some Issues v How isolated are users? v How is a path defined? –e.g. /user1/foo v How do users access system files? –copying –(extendible) search paths

25. OSes: 10. FileSys Intf. 25 3.3. Tree-structured Directory Fig. 10.9, p.354 listallcount listrade countlist dictspell words w7 w root continued

26. OSes: 10. FileSys Intf. 26 v Treat a subdirectory like another file –use a special bit in the directory entry to distinguish a file (0) from a subdirectory (1) v Absolute vs. relative path names? –e.g. /spell/words/rade../spell/words/rade v How is a non-empty subdirectory deleted?

27. OSes: 10. FileSys Intf. 27 3.4. Acyclic Graph Directory Fig. 10.10, p.357 listallcount listrade countlist dictspell words w7 w root continued

28. OSes: 10. FileSys Intf. 28 v A natural generalisation of a tree-structured directory scheme –allows files/subdirectories to be shared v How are cycles avoided? v A file/subdirectory may have multiple absolute path names –complicates traversal continued

29. OSes: 10. FileSys Intf. 29 v How are shared files/subdirectories deleted? –leave ‘dangling pointers’ (cheap) –use an access list (expensive) –use a reference count

30. OSes: 10. FileSys Intf. 30 Sharing in UNIX v Symbolic links –a pointer to another file/subdirectory –easily identified by a bit set in the file entry –deletion leaves links ‘dangling’ v Hard links –keep a reference count for hard links to a file –cannot link to a subdirectory u avoids cyclic graphs

31. OSes: 10. FileSys Intf. 31 3.5. General Graph Directory Fig. 10.10, p.357 textmailbook avicount bookmail avijim count root continued

32. OSes: 10. FileSys Intf. 32 v Traversal could go into an infinite loop –use a bounded search v A subdirectory that refers to itself will never have a reference count of 0 –not possible to delete it v Garbage collection is required to reclaim inaccessible files/subdirectories –very expensive

33. OSes: 10. FileSys Intf. 33 4. Protection v Protection mechanisms control/limit file and directory access operations, such as: –reading, writing, execution, appending, deletion, listing v Protection levels and types depend on the system –PC --> corporate installation

34. OSes: 10. FileSys Intf. 34 4.1. Access Lists & Fields v Access List –specify access rights for every user of every file –tedious; leads to very large lists v Fields (Groups) –owner/group/world –each field in UNIX has 3 bits for read, write, and execute permissions

35. OSes: 10. FileSys Intf. 35 UNIX Example v bazooka 47: ls -l total 62 drwxr-xr-x 2 ad 512 Nov 4 1998 Figures/ -rw-r--r-- 1 ad 14109 Nov 12 1998 Listings -rw-r--r-- 1 ad 1878 Nov 4 1998 abstract.tex -rw-r--r-- 1 ad 782 Nov 4 1998 cover-note drwxr-xr-x 2 ad 512 Feb 16 08:59 old_code/ -rw-r--r-- 1 ad 24450 Nov 4 1998 progHTTP.txt drwxr-xr-x 2 ad 512 Nov 12 1998 revisted/ -rwxr-xr-x 1 ad 11676 Feb 16 08:52 sock_brow* -rw-r--r-- 1 ad 4150 Dec 22 17:07 sock_brow.c -rw-r--r-- 1 ad 887 Nov 4 1998 web-tech-addr Fig. 10.12, p.364

36. OSes: 10. FileSys Intf. 36 4.2. Passwords v A password per file –too hard to remember v A password per subdirectory –too course-grained

37. OSes: 10. FileSys Intf. 37 5. Consistency Semantics v Consistency semantics is how an OS deals with modifications to a shared file by multiple users who are accessing the file at the same time.

38. OSes: 10. FileSys Intf. 38 Consistency Sems for UNIX v A write is immediately visible to every shared users. v Processes may share the current position pointer of the file. v Users see a shared file as representing a single physical entity.

39. OSes: 10. FileSys Intf. 39 Consistency Sems for Andrew FS v A distributed file system from CMU. v A write is not immediately visible. v A change becomes visible to subsequent opens after the file has been closed. v Users see a shared file as representing several temporary (possibly different) images of the single physical entity.

40. OSes: 10. FileSys Intf. 40 Immutable Shared Files v A type of file which cannot be modified if it is declared as shareable by its creator. v Greatly simplifies sharing in a distributed file system.