Content

Introduction
1. Relevance of the topic
2. Purpose and objectives of the research, planned results
3. Research and development overview
3.1 Ext2Fsd
3.2 DiskInternals Linux Reader
3.3 Plugin for Total Commander DiskInternals Reader
3.4 Ext2explore
4. Ext4 filesystem overview
5. Approach to development of file system driver
5.1 Interaction of the user program with the driver
5.2 File system driver development
Conclusions
References

Introduction

If you are a user of the Linux operating system, then you should know that it does not want to conflict with Windows, this manifests itself in everything. For example, it can determine the presence of this operating system, which will allow you to select the system you need to work when you boot your computer, plus you can work with hard disk partitions without any problems (if we are talking about NTFS and FAT file systems), you will be able to organize file sharing. But under Windows OS, you cannot do this without special software.

1. Relevance of the topic

Basically, our hard drives have more than one partition and these partitions may not always be the same file system. For example, Windows often has FAT and NTFS partitions, and UNIX-based operating systems have an ext file system. It is not uncommon for system programmers to have multiple operating systems on their machines, and access to different file systems is very important. However, Windows OS cannot see partitions of the ext file system without additional software.

2. Purpose and objectives of the research, planned results

The aim of the master's thesis is to research and develop an ext4 file system data access driver at the Windows kernel level.

An application accessing an ext4 partition from the Windows OS must be able to access low-level disk access functions. These functions are performed by the file system driver, a program that runs in the Windows kernel mode. Kernel mode is the privileged mode associated with the hardware protection ring of the processor. It is characterized by the privileges of code access to resources (memory, processor, devices, etc.), which is necessary during the development of a program [3]. Therefore, the software developed must consist of a program providing a user interface and a file system driver.

3. Research and development overview

3.1 Ext2Fsd

Ext2Fsd is a driver for the ext filesystem (versions 2\3\ 4), it implements support for these filesystems at the operating system kernel level. You can work with disk partitions and drives formatted in these file systems as with normal Windows-supported information devices in the Explorer window or third-party programs. The driver allows you to transparently read and write data [1]. During software installation, the user can select the supported versions of the ext file system, as well as automatically mount partitions at system startup after installation, the Volume Manager will be launched, where the user can mount the ext partition with the choice of the partition letter. The driver provides two options for mounting a partition at mount time:

• Automaticly mount via Ext2Mgr - the partition will be connected now, but only until the reboot;
• Mountpoint for fixed disk - permanent automatic connection of the partition at system startup.

Advantages: ease of use, free license, mounting ext partitions at the Windows kernel level, ext partitions are visible in Windows Explorer.
Disadvantages: does not support journaling of the ext4 file system, has not been updated for a long time and no new software versions are planned.

3.2 DiskInternals Linux Reader

DiskInternals Linux Reader is free and allows you to access files from Ex2/3/4, UFS2, HFS and ReiserFS/4 file systems. In addition, the tool can read common Windows supported file systems like NTFS, Fat, exFat, etc.

The program has a neat interface that is similar to Windows Explorer, making Linux Reader very easy to use. The program has almost all the standard features like search box, navigation buttons, recent files and folders. You can also specify the view and sort the files by all available properties [1].

If you are at the root of a disk, Linux Reader will show you statistics - for example, the number of different file types. A pie chart is also displayed.

Linux Reader also allows you to mount source disk images or virtual disks. In this way, any work done in the virtual machine can also be retrieved and all files can be easily accessed. This is useful if you do a lot of virtual machine work or if you have a disk image of your filesystem.

Advantages: large list of file systems, guaranteed product support, intuitive interface.
Disadvantages: opens the section in read-only mode, you have to pay for advanced features.

3.3 Plugin for Total Commander DiskInternals Reader

Fans of the popular Total Commander can extract Linux or Android data inside Windows using this file manager. But having previously installed a special plugin in it. One of these plugins is DiskInternals Reader, it can connect and read information devices formatted in Ext2/3/4, Fat/exFAT, HFS/HFS +, ReiserFS. It is worth replacing that to work with this plugin, Total Commander must be run only as administrator. Data is copied in the traditional way for Total Commander - by pressing F5 to the second panel.

3.4 Ext2explore

A program designed to view EXT2, EXT3 or EXT4 partitions of the Linux file system through the Windows operating system. Ext2explore's interface is very easy to use and has two separate windows for viewing files.

The first thing you need to do is connect your hard drive with ExtFS partitions to your computer and open a new file system or disk image. The program also provides support for external drives for quick file access.

Ext2explore displays the contents of sections in the main window, thereby allowing you to view and modify files in the Linux EXT section, without the need to install other third-party applications.

You can also create new files or folders, use basic editing tools to work with files, cut, copy, paste, rename or delete files on EXT2, EXT3 or EXT4 sections, and save changes.

4. Ext4 filesystem overview

Ext4 is the fourth version of the Fourth Extended File System. The core of Ext4 is to divide the entire section space into blocks. A 1024 byte portion of the zero block data is reserved for the bootloader or other system needs. This array is followed by a superblock (ext4 Super Block). Block numbers are counted from 0. If the block size is 1024, then the superblock is not in the zero block, but in the first one. The superblock is followed by group 0. The structure of the group is shown in Figure 6 [2, 3]].

One of the most valuable features of a file system is low data fragmentation. This is achieved through the following mechanisms [4]

• Extents. Extent is a descriptor describing a section of several contiguous blocks. The standard file system keeps track of file data blocks using an indirect block scheme, which is efficient for small files, but highly fragmented large files. Extents allow you to address up to 128 MB of disk space with a block size of 4 KB. For small files, 4 extents can be stored directly in the inode;
• Deferred distribution. This is a way to improve productivity. The bottom line is that the allocation of blocks on a partition does not occur at the moment write () is called, but at the moment the cache is dumped to disk. This allows programs that constantly call write () not to load the system. In addition, this allows you to determine the file sizes in advance and optimize the allocation of extents. In this case, short-lived files may not get to the ROM at all;
• Log checksums. Since the log is a frequently used part of the disk, you must protect this data area from failure. Therefore, ext4 calculates the checksums of the data from the log to determine whether it is corrupted.

5. Approach to development of file system driver

5.1 Interaction of the user program with the driver

A user program can interact with a driver on the system in two ways:

• Implicit - call a typical Win32 API function;
• Explicit - Direct I/O request to the driver.

In the first case, a Win32 API function (for example, CreateFile) is called in the application program, which, then, depending on the target object (file, directory), it can call the exchange function with the driver in the chain of its calls. In fact, in this case, the application code does not set itself the task of interacting with any driver, just along the chain of procedure calls, at a certain stage the execution goes into kernel mode and the driver function is called there. All this remains hidden from the developer, however, it is possible to trace the interaction using debugging tools. The second case occurs when a driver call means a non-indirect call (by calling a type function), and the transmission using a special function (for example, DeviceIoControl) of the so-called I/O control request, which, further, initiates the formation of a data block called an I/O request packet. Since any driver is considered an I/O participant, Windows sends them special packets - IRPs (I/O Request Packet). Moreover, the interaction of the user program with the driver occurs only through system calls (Windows API). This call causes the I/O manager to generate an IRP based on it. The driver that this package is sent to may delay the task execution. This is how Windows supports asynchronous I/O.

5.2 File system driver development

A file system driver (FSD) is a driver that controls the format of a file system. To work, he needs to register with the I/O manager, and also work closely with the memory manager to manage the cache. After the driver is registered, the manager can call it to recognize the file system volumes. The recognition process includes boot sector analysis and file system metadata analysis. If the volume is not recognized, it is assigned a Raw driver, which prompts you to format the volume. The Raw driver provides sector-level reads and writes, which still allow access to the device [5]. The most common way to access files is to call the CreateFile, ReadFile, WriteFile functions. The file is opened using the CreateFile function. It calls the NtCreateFile function, which is passed the full path to the file name with the "\ ??" prefix. In turn, NtCreateFile calls the ObOpenObjectByName function, which parses the name and, using the object manager, converts the drive letter to \ Device \ HarddiskVolume (x), where (x) is the number assigned to the partition by the system. The IopParseDevice function, which it calls, checks the security data and generates an IRP request IRP_MJ_CREATE. The request is then passed, using the IoCallDriver function, to the driver itself. The driver must find the required file and, if the search is successful, and if the credentials match, it must return a success code. The object manager creates a descriptor for the file object and chains it back to CreateFile. This can be followed by various calls to read and write files. With Windows 2000, the Windows driver model (WDM) replaced the VxD driver model. It had advanced features, but the complexity of writing and maintaining code increased. To facilitate the development process, Microsoft released the WDF (Window Driver Frameworks) framework, which brought with it two toolkits: the Kernel Mode Driver Framework (KMDF) and the User Mode Driver Framework (UMDF). The first is for writing standard kernel-level drivers, and the second is for writing specific driver classes that can be executed at the user level.

Conclusions

At the time of this writing:

• analysis of the current state of the problem has been carried out;
• analysis and comparison of existing solutions and the file system has been carried out;
• directions for further research are outlined.

The utilities considered are not the only ones for solving the problem of access from Windows to partitions with the Ext4 file system. However, most programs have similar disadvantages - not providing full access to such a section. Therefore, the task of developing an application that provides full access to sections with Ext4 from Windows remains urgent. The structure of the Ext4 file system, which is typical for most UNIX operating systems, differs in many respects from the file systems of Windows. Therefore, at the first stage of application development, it is necessary to consider the features of this file system.

The ext4 file system driver for Windows is required because there is still no full write-mode file system implementation. Further research and development will be related to writing a driver in the C / C ++ programming language. With this driver, a Windows user can easily mount partitions, read and edit ext4 filesystems. Based on the analysis of the advantages and disadvantages of existing solutions, having studied the structure and methods of accessing the ext4 file system, we can set the requirements for a driver that can provide read and edit access to files and directories of the ext4 FS from under Windows:

• ability to transparently mount ext4 file system partitions;
• speed of reading and editing the contents of the section (this item implies the use of caching mechanisms);
• support for encrypted directories is planned in the future.

References