File Systems Windows XP Professional supports the FAT16, FAT32, and NTFS file systems.

Because NTFS has all the basic capabilities of FAT16 and FAT32, with the added advantage of advanced storage features such as compression, improved security, and larger partitions and file sizes, it is the recommended file system for Windows Vista. Some features that are available when you choose NTFS:

File encryption allows you to protect files and folders from unauthorized access. Permissions can be set on individual files, as well as on folders. Disk quotas allow you to monitor and control the amount of disk space used by individual users. Better scalability allows you to use large volumes. The maximum volume size for NTFS is much greater than it is for FAT. Additionally, NTFS performance does not degrade as volume size increases, as it does in FAT systems. Recovery logging of disk activities helps restore information quickly in the event of power failure or other system problems.

The new Vista file system works on the following (ACID) transaction principles: a. Atomicity In a transaction involving two or more discrete pieces of information, either all of the pieces are committed or none are. b. Consistency A transaction either creates a new and valid state of data, or if any failure occurs, returns all data to its state before the transaction started. c. Isolation A transaction in process and not yet committed must remain isolated from any other transaction. d. Durability Committed data is saved by the system such that, even in the event of a failure and system restart, the data is available in its correct state.

The file system stores various file names and associated file properties in to a table, in a specialized database form. The table which is used to store various file properties including file names is called FAT (File Allocation Table). Each row in the table consists of name of the file and its associated attributes. The computer system allots a portion of hard disk, for maintaining these entries. Each partition has got its own file allocation table. When the user needs some information he informs computer with a filename. The computer looks for entries in the file allocation table, for a matching filename in it. If it is not found, then it returns error. However, if it is found, the computer retrieves the contents, by using programs meant for that, by accessing additional information provided for the filename in the file allocation table.

File allocation table The file system in a computer is classified into many types, depending on the file allocation table. In Microsoft family of operating systems, we see mostly FAT16, FAT32, and NTFS as file systems. We today, make use of FAT32 as a standard file system. Prior to FAT32, FAT16 was the standard. FAT16 still used in case of Floppy disks and still remains alive for

backward compatibility in the latest operating system releases. NTFS - New Technology File System was first implemented in Server operating systems. Started from mid 1993, the file system provides a better way of securing the contents of the file. It also introduced many additional properties, which the FAT did not have. Windows 95 was perhaps the first OS to implement the FAT32. This operating system wrote perhaps a new book in history of computers for many reasons. Apart from implementing FAT32, this introduced many new features which were not existed in earlier systems, including changes in GUI design. But, before 1995, Microsoft as said above, during 1993, released NTFS, only for server side operating system Windows NT 3.1. One can install Windows 2000 Server, Windows XP in FAT32 partition also, but, without NTFS features. The NTFS features include read permission which was not there with FAT. Dont get confused with Read Only attribute in FAT. The Read Only attribute tells the computer to deny write capability for the file. But, of course, any who logs into the computer can read the file. Therefore, it was decided to introduce Read permission settings. The creator of the file or administrator can decide whether to permit or deny the file for viewing. This is one of the significant features which were introduced in NTFS. Other features in NTFS include active directory, file indexing, disk quotas, compression, encryption and many more. The drawback of NTFS is, one cannot go back to FAT32 or FAT later, without loosing the data. File Indexing and Active directory enable to search the required file as quick as possible. Data compression enables one to store data more than the actual available space. Data encryption ensures that the files are safe. Disk quotas will allot each user, his share of disk space. If disk quota is not implemented, then any user can use all available space on the system, if he can log into the system. Disk quota will help server systems in keeping track of used space. Earlier, one was needed to write separate programs to manage available disk space in the server. Windows Vista & NTFS Windows Vista, the new operating system makes use of NTFS as a default file system. This means, one cannot install Windows Vista, to a non-NTFS partition. The setup program will show only the NTFS partitions. So, use convert.exe from the command prompt from Windows XP, to convert the existing partition to NTFS. Before converting, it is advisable to take data backup from the system, because, any error could corrupt the existing data, beyond recoverable limit. Some earlier versions of Windows, especially Windows 95, 98 cannot read the NTFS partitions created on local system (Local system is referred to as your computer). Therefore, you should keep other partitions as FAT if you have already installed Windows 95, 98 and ME and want to use the same. They may be designed to read NTFS from a network server which is a different case. After converting the partition into NTFS from FAT32 or FAT, one should be able to install Windows Vista on that partition. One should format the partition after that process to ensure the partition is empty. It is better to have an empty partition on the hard drive to install Windows Vista, as the required amount of free space is quite high. FAT32 or FAT16 has got several disadvantages, when compared to NTFS. Apart from nonavailability of new features of NTFS, FAT32 also has got limitations on file and partition sizes. One cannot store a file greater than 4 GB. Also, one cannot have partitions of greater size of 32 GB.

File and Path A file can be found and identified by its path. A Path consists of Drive letter of partition followed by folder name which is followed by the subfolder if any, followed by the filename. The letter \ is used to separate the drive letter, folder, subfolder, and the filename. The letter : is used after the Drive letter. Therefore, it is Driveletter:\Folder\SubFolder\FileName.Extension is the actual path for accessing any particular file. The extension is used to determine the type of file. For example, the extensions bmp, jpg, gif tells the computer that the file contains picture as data. Similarly the extension doc is used to represent word documents and txt for simple text documents. The extension also decides program which opens the file. Early Days: During the MS-DOS days, the filename was of 8 characters in length. One could give a meaningful filenames with this length. The extension is of 3 characters. It was from Windows 95 onwards, one was able to give long filenames. The length of the filename was increased to 255 characters. The Vista Generation: Windows Vista, the next generation of operating system in the Windows family, introduces newer set of tools, options to its users. Among them is the look of folder icons. A folder containing files and subfolders will be displayed as icon containing few papers in it. An empty folder will be displayed without papers in it. In the earlier, one was needed to view the size of the folder to know whether the folder is empty or not. The files and folders will be better organized in Windows Vista, when compared to other previous versions. The user need not know the basic concept of well organizing files and folders in Windows Vista, because, it automatically creates folders in a well organized way during installation itself, under a folder, which is named with the user name. Such folders are called personalized folders. One needs only to save the particular type of file in the folder which is named for the same. The computer does not restrict the user to save a particular type of file into folder which is meant for it. One can save anywhere they wish. But, it is better to save the files in the folders which are meant for it, thus, enabling the user to organize files.

Comparison of NTFS and FAT File Systems

Subject of Comparison Operating system compatibility

NTFS A computer running Windows Vista, Windows Server 2003, Windows 2000, or Windows XP can access files on an NTFS partition. A computer running Windows NT 4.0 with Service Pack 4 or later can access files on the partition, but some

FAT16 File access is available to computers running Microsoft MSDOS, all versions of Windows, Windows NT, Windows XP, Windows Vista, and

FAT32 File access is available only to computers running Microsoft Windows 95 OSR2, Windows 98, Windows Me, Windows 2000, Windows XP, and

NTFS features, such as Disk Quotas, are not available. Other operating systems allow no access. Volume size Recommended minimum volume size is approximately 10 MB. Recommended practical maximum for volumes is 2 terabytes. Much larger sizes are possible. Cannot be used on floppy disks. Maximum file size 16 terabytes minus 64 KB (244 minus 64 KB) 4,294,967,295 (232 minus 1 files)

OS/2.

Windows Vista.

Volumes up to 4 GB. Cannot be used on floppy disks.

Volumes from 512 MB to 2 terabytes. In Windows Vista, you can format a FAT32 volume only up to 32 GB. Cannot be used on floppy disks. Maximum file size 4 GB Approximately 4,177,920

File size Files per volume

Maximum file size 4 GB 65,536 (216 files)

Win32 file functions: Win32::CopyFile(FROM, TO, OVERWRITE) [CORE] The Win32::CopyFile() function copies an existing file to a new file. All file information like creation time and file attributes will be copied to the new file. However it will not copy the security information. If the destination file already exists it will only be overwritten when the OVERWRITE parameter is true. But even this will not overwrite a read-only file; you have to unlink() it first yourself. Win32::CreateDirectory(DIRECTORY) Creates the DIRECTORY and returns a true value on success. Check $^E on failure for extended error information. DIRECTORY may contain Unicode characters outside the system codepage. Once the directory has been created you can use Win32::GetANSIPathName() to get a name that can be passed to system calls and external programs. Win32::CreateFile(FILE) Creates the FILE and returns a true value on success. Check $^E on failure for extended error information. FILE may contain Unicode characters outside the system codepage. Once the file has been created you can use Win32::GetANSIPathName() to get a name that can be passed to system calls and external programs. GetFolderPath(FOLDER [, CREATE])

Returns the full pathname of one of the Windows special folders. The folder will be created if it doesn't exist and the optional CREATE argument is true. The following FOLDER constants are defined by the Win32 module, but only exported on demand: Win32::GetFullPathName(FILENAME) [CORE] GetFullPathName combines the FILENAME with the current drive and directory name and returns a fully qualified (aka, absolute) path name. In list context it returns two elements: (PATH, FILE) where PATH is the complete pathname component (including trailing backslash) and FILE is just the filename part. Note that no attempt is made to convert 8.3 components in the supplied FILENAME to longnames or vice-versa. Compare with Win32::GetShortPathName() and Win32::GetLongPathName(). If supported by the core Perl version, this function will return an ANSI path name if the full pathname cannot be represented in the system codepage. Win32::GetLongPathName(PATHNAME) [CORE] Returns a representation of PATHNAME composed of longname components (if any). The result may not necessarily be longer than PATHNAME. No attempt is made to convert PATHNAME to the absolute path. Compare with Win32::GetShortPathName() and Win32::GetFullPathName(). This function may return the pathname in Unicode if it cannot be represented in the system codepage. Use Win32::GetANSIPathName() before passing the path to a system call or another program. Win32::GetShortPathName(PATHNAME) [CORE] Returns a representation of PATHNAME that is composed of short (8.3) path components where available. For path components where the file system has not generated the short form the returned path will use the long form, so this function might still for instance return a path containing spaces. Returns undef when the PATHNAME does not exist. Compare with Win32::GetFullPathName() and Win32::GetLongPathName().

Windows Vista defines a User Profile namespace, which is a namespace of folders that end users and applications use for storing files. The structure of this namespace is intended to enable end users, applications, administrators, and the operating system to best use the storage features offered by the file system. To decide where files should be stored, you must consider several issues.

computer, or accessed through a network? the file need to be written to by the user or should it be read only? Defining Data Categories and Their Storage Locations in the File System

All the data on a computer falls into several categories. This section explains this categorization and clarifies where data from each category should be stored. End-User-Managed Data vs. Application-Managed Data End-user-managed data is typically data that a user might interact with directly (for example, documents, music files, pictures, and so on) and should go in the storage locations that users consider theirs. Windows makes these locations discoverable and efficient to access by providing entry points in the user interface (UI). For example, the Windows Explorer namespace (in the form of desktop icons, the folder tree, and the breadcrumb bar), the Start menu, and the File, Open, and Save dialog boxes are all designed to make it easy for the user to access these locations quickly. For the purpose of this document, we will call these folders user-data folders. Visible folders in the users profile and the public profile exist to store enduser-managed data. C:\Users\<username>\<ContentType> (for example, C:\Users\<username>\Documents) C:\Users\Public\<ContentType> (for example, C:\Users\Public\ Documents) Application-managed data, which, typically, a user never interacts with directly (for example, Microsoft Office Word toolbar settings), should go in folders that are less visible in the UI. These folders are hidden and placed in locations that users normally do not encounter. There are per-user and public forms of these folders as well as roaming, local, and low-rights forms. C:\Users\<username>\AppData (hidden) C:\ProgramData (hidden) Because it is common for certain types of files to be end-user managed and application managed, consider the following characteristics for each of these types of data and select the most appropriate storage location for these files. Per-User Data vs. Shared-User Data All end-user-managed data can be further categorized into data that might belong to a specific user, which only they can directly interact with, or data that is shared with all users on a machine. Storing Per-User Data Data that should be private to a user and maintained separately from other users of the same computer should be stored in user-data folders within the users own profile. The peruser folders are secured through Access Control Lists (ACLs) so that, under default circumstances, each users storage space is private. Storing Shared-User Data Data that should be accessible to multiple users of the computer or other users or devices on the network should be stored within the public folders located at C:\Users\Public. This location uses a public/private sharing model, so only data that should be accessible to everyone should be placed there. Files that require discretionary access should remain in the users profiles and should have the appropriate ACL set on them. Program Files vs. Per-User or Shared-Application Data Windows Vista provides specific locations in the file system to store programs and software components, application data that is shared between all users on a computer, and application data that is specific to a user. These locations are, respectively: \Program Files: o Storage location for programs and software components. o Users should not store any user data or application data here because of the security permissions configured for this folder. Standard users do not have rights to write data to this location.

\ProgramData: o Storage location for application data that is to be shared between all users on that computer. \Users\<username>\AppData: o Storage location for per-user application data that is exclusive to a user and should not be shared with any other user on that computer. o The AppData location itself has a further hierarchy below it to differentiate computerdependent application data from computer-independent application data. This hierarchy is discussed in detail in the next section. Further Categorization of Application Data All application-managed data can be further categorized into data that belongs to a specific user and is managed by an application exclusively for that user, or data that can be shared with all users of that computer. Storing Per-User Application Data Windows Vista provides a specific hierarchy for application developers when storing application data within the users profile. The C:\Users\<username>\AppData folder is further subdivided into the following three discrete folder paths: \Local folder for storing computer-dependent data \Roaming folder for storing computer-independent data \LocalLow folder for storing low-rights integrity data When storing per-user application data within the user profile, you can use the following procedure to determine where to store the data: 1. Determine the type of application data you are storing in the file system. Is it computerdependent, computer-independent, or low-rights integrity data? Based on that information, use one of the following paths to store the data: C:\Users\<username>\Appdata\Roaming For per-user computer-independent application data. Can be roamed or redirected within an organization by using folder redirection or roaming user profiles. Computer-independent application data that contains a user's customizations and cannot be recreated without explicit user action. C:\Users\<username>\Appdata\Local For per-user computer-dependent application data. Should not be roamed or redirected within an organization. Application data that contains only temporary or non-critical data that can be discarded without affecting the application's functionality. (For example, log files for debugging purposes.) Application data which, although machine independent, can easily be re-created without explicit user action, as it does not store any user-generated customizations or settings. C:\Users\<username>\Appdata\LocalLow

 For per-user low-rights application data. Meant as a location to be used by low-rights applications to store their data. Will not be roamed or redirected in an organization. 2. Create a subfolder under the appropriate AppData folder above using the following convention: Step A: ..\Vendor Name\Major Product Name (Recommended) For example: AppData\Roaming\Microsoft\Office Step B: ..\Minor Product Name (Optional) For example: AppData\Roaming\Microsoft\Office\Groove Step C: ..\Version + SKU Information (Optional) For example: AppData\Roaming\Microsoft\Office\Groove\2007 Ultimate Edition Storing Shared Application Data All application data that must be shared among users on the computer should be stored within the C:\ProgramData folder location. To store data for your application, create a subfolder under the C:\ProgramData\ folder by using the following convention: Step A: ..\Vendor Name\Major Product Name (Recommended) For example: C:\ProgramData\Microsoft\Office Step B: ..\Minor Product Name (Optional) For example: C:\ProgramData\Microsoft\Office\Groove Step C: ..\Version + SKU Information (Optional) For example: C:\ProgramData\Microsoft\Office\Groove\2007 Ultimate Edition Creating Folders at the Drive Root An application should not create files or folders at the root of the system drive and should use the folder structure as described in previous sections to store their program and software components, application data, and user data. An application can enable relocation of folders it manages by using the Folder Redirection feature in the Windows operating system. This enables the end user to make the decision to relocate that data if they Namespace Usage Guidelines for the Windows Vista File System 15

want to, such as to the root of the disk, to another local disk, or to a network location. Folder redirection was part of Windows 2000 and Windows XP, but was limited to only the My Documents, My Pictures, Desktop, Application Data, and Start Menu folders. Windows Vista allows a larger selection of known folders to be redirected. Applications can also enable a custom folder to be redirected in their folder definition when they create the folder using the Known Folder APIs as described on MSDN at http://msdn2.microsoft.com/enus/library/ms645247.aspx. SHGetKnownFolderPath Function vs. the SHGetFolderPath Function SHGetKnownFolderPath (http://msdn2.microsoft.com/enus/library/ms647783.aspx) is a new function in Windows Vista that is a superset of SHGetFolderPath (http://msdn2.microsoft.com/en-us/library/ms647764.aspx), which was included in earlier versions of the Windows Shell. The SHGetFolderPath function, although a legacy function, is still supported in Windows Vista. SHGetFolderPath provides programmatic access to a subset of the well known folder locations in Windows Vista through a set of constants called constant special item ID list (CSIDL) constants. These constants are documented on MSDN at http://msdn2.microsoft.com/enus/library/ms649274.aspx. Namespace Usage Guidelines for the Windows Vista File System 16 2007 To programmatically access all Windows Vista well known folder locations, including well known folders that your application created, use the SHGetKnownFolderPath function. You can use the SHGetFolderPath function if all of the following are true:

that is accessible on both Windows Vista and Windows XP, you are using only the well known folder locations that are supported on Windows XP.