a working XFS driver for Windows
Introduction
When you are looking for a driver of XFS, a well-known filesystem for Unix, for the Windows operation system, Linux forums leave the bitter word “impossible” in your heart. If you end up here for the same reason, I have good and bad news for you. The good news is, there is a XFS driver for Windows by Crossmeta/Pavitrasoft. Yes, it works despite what you read on the web. The bad news is, it works with old versions of XFS only. I guess this is a stumbling point for many users. Another obstacle is the absence of reasonable documentation for the driver and the presence of outdated skimpy tutorials. This is true even for the official manual. No wonder users feels frustrated.
This manual expects you to know basic commands and command-line shells of Linux and Windows, for example, how to view contents of a directory.
Installation
I tested the driver on 32-bit Windows 7 Professional. Download and unpack 2 packages (drivers and addons) from the download page. I picked the version 1.2. Install drivers, then addons, by running “setup.exe”. I suppose you should reboot Windows afterwards.
Starting the driver
Log in to Windows as Administrator. Start a command line shell. Start the “CROSSMETA Manager service” by net start cxvfsmgr. Then the disk v appears containing a mini-Unix environment. There is no documentation on its commands, and command options differ from what we have on Linux. The disk v is the root of your Unix environment. Unix commands require paths relative to the root. Paths should be written as in Unix. Run set path=%path%;v:\bin. If you need to see v in the Windows Explorer, restart it. Start the “CROSSMETA SGI-XFS kernel mode driver” by net start xfs. You are ready for work.
Troubleshooting
The command dmesg shows the log. There are commands which do not show an error, so check the log when in doubt.
Devices
Device files are in the directory /dev. I don't know what hell their naming scheme comes from. da${X} is a ATA device, and da${X}s${Y} is a partition, where X and Y are numbers. I can't say how to get more info on these devices, so we need to guess which is which. This is why you may want to practice on a disk image file.
If you do, create a disk image file FILE, for example, by diskpart in Windows. Create a device file /dev/$NAME by losetup $NAME $FILE where FILE is (attention!) the Windows path. NAME can be loop1, for example.
Creating a XFS filesystem
I bet that the change that made the Crossmeta driver incompatible with recent versions of XFS is described here. So we should create a clean XFS filesystem of an older version. There are 2 ways to do this. Way 0. Run xfs_mkfs $DEVICE in Windows where DEVICE is the device file of the partition where you put the filesystem. This command is included in the Crossmeta driver. Way 1. Run mkfs.xfs -n ftype=0 -m crc=0 $DEVICE in Linux. This way, you are disabling some features of XFS. Beware that I found these parameters by experiment, so Way 1 does not seem as safe as Way 0.
Mounting
mount -t xfs $DEVICE $MOUNT_POINT as usual. MOUNT_POINT can be /mnt, for example. It seems that the driver simply omits files having non-ASCII characters in their names. On successful mount, you'll see in the log
XFS mounting filesystem $DEVICE
Ending clean XFS mount for filesystem: $DEVICE
Otherwise, you'll see a variant of
XFS: bad version
XFS: SB validate failed
ntstatus: unmapped error = 991
umount $MOUNT_POINT unmounts as usual. A filesystem can't be unmounted if the Windows Explorer shows it.
Conclusion
Actually, this task turned out to be easy in contrast to what I was preparing for. In its current state, the driver is not as useful as it can be. I believe that Crossmeta programmers are able to upgrade their driver so it will support the newest version of XFS, but, unfortunately, I was not able to reach them.
When you are looking for a driver of XFS, a well-known filesystem for Unix, for the Windows operation system, Linux forums leave the bitter word “impossible” in your heart. If you end up here for the same reason, I have good and bad news for you. The good news is, there is a XFS driver for Windows by Crossmeta/Pavitrasoft. Yes, it works despite what you read on the web. The bad news is, it works with old versions of XFS only. I guess this is a stumbling point for many users. Another obstacle is the absence of reasonable documentation for the driver and the presence of outdated skimpy tutorials. This is true even for the official manual. No wonder users feels frustrated.
This manual expects you to know basic commands and command-line shells of Linux and Windows, for example, how to view contents of a directory.
Installation
I tested the driver on 32-bit Windows 7 Professional. Download and unpack 2 packages (drivers and addons) from the download page. I picked the version 1.2. Install drivers, then addons, by running “setup.exe”. I suppose you should reboot Windows afterwards.
Starting the driver
Log in to Windows as Administrator. Start a command line shell. Start the “CROSSMETA Manager service” by net start cxvfsmgr. Then the disk v appears containing a mini-Unix environment. There is no documentation on its commands, and command options differ from what we have on Linux. The disk v is the root of your Unix environment. Unix commands require paths relative to the root. Paths should be written as in Unix. Run set path=%path%;v:\bin. If you need to see v in the Windows Explorer, restart it. Start the “CROSSMETA SGI-XFS kernel mode driver” by net start xfs. You are ready for work.
Troubleshooting
The command dmesg shows the log. There are commands which do not show an error, so check the log when in doubt.
Devices
Device files are in the directory /dev. I don't know what hell their naming scheme comes from. da${X} is a ATA device, and da${X}s${Y} is a partition, where X and Y are numbers. I can't say how to get more info on these devices, so we need to guess which is which. This is why you may want to practice on a disk image file.
If you do, create a disk image file FILE, for example, by diskpart in Windows. Create a device file /dev/$NAME by losetup $NAME $FILE where FILE is (attention!) the Windows path. NAME can be loop1, for example.
Creating a XFS filesystem
I bet that the change that made the Crossmeta driver incompatible with recent versions of XFS is described here. So we should create a clean XFS filesystem of an older version. There are 2 ways to do this. Way 0. Run xfs_mkfs $DEVICE in Windows where DEVICE is the device file of the partition where you put the filesystem. This command is included in the Crossmeta driver. Way 1. Run mkfs.xfs -n ftype=0 -m crc=0 $DEVICE in Linux. This way, you are disabling some features of XFS. Beware that I found these parameters by experiment, so Way 1 does not seem as safe as Way 0.
Mounting
mount -t xfs $DEVICE $MOUNT_POINT as usual. MOUNT_POINT can be /mnt, for example. It seems that the driver simply omits files having non-ASCII characters in their names. On successful mount, you'll see in the log
XFS mounting filesystem $DEVICE
Ending clean XFS mount for filesystem: $DEVICE
Otherwise, you'll see a variant of
XFS: bad version
XFS: SB validate failed
ntstatus: unmapped error = 991
umount $MOUNT_POINT unmounts as usual. A filesystem can't be unmounted if the Windows Explorer shows it.
Conclusion
Actually, this task turned out to be easy in contrast to what I was preparing for. In its current state, the driver is not as useful as it can be. I believe that Crossmeta programmers are able to upgrade their driver so it will support the newest version of XFS, but, unfortunately, I was not able to reach them.