3

My problem is to decode the output of the command file -s /dev/sdX on my system (where /dev/sdX is the device file associated to a USB key).
Below I'll show the output of the command file -s /dev/sdX where the device file /dev/sda1 is a partition formatted with a FAT32 filesystem, while the device /dev/sdb is a partition formatted with a NTFS filesystem.

Output of file command for a FAT32 filesystem

In the case of the FAT32 filesystem the output of the file command is:

> file -s /dev/sda1 /dev/sda1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "mkfs.fat", sectors/cluster 8, Media descriptor 0xf8, sectors/track 62, heads 31, hidden sectors 2048, sectors 1966080 (volumes > 32 MB), FAT (32 bit), sectors/FAT 1920, reserved 0x1, serial number 0x4ba3ff5b, unlabeled

In the output is present the information , FAT (32 bit), sectors/FAT 1920, which could be enough to say that the filesystem type is FAT32, but in the next paragraph I'll show that the string FAT is also present in the output of the file command in the case of an NTFS filesystem.

Output of file command for a NTFS filesystem

In the case of a NTFS filesystem the output of the file command is:

> file -s /dev/sdb /dev/sdb: DOS/MBR boot sector, code offset 0x52+2, OEM-ID "NTFS ", sectors/cluster 8, Media descriptor 0xf8, sectors/track 63, heads 255, dos < 4.0 BootSector (0x0), FAT (1Y bit by descriptor); NTFS, sectors/track 63, physical drive 0x80, sectors 15654911, $MFT start cluster 786432, $MFTMirror start cluster 2, bytes/RecordSegment 2^(-1*246), clusters/index block 1, serial number 030fcd5a9fcd56a1c; contains bootstrap BOOTMGR

In this output is present the information ; NTFS, but it is also present the string FAT.

The question

From the previous outputs of the file -s command, how to determine the filesystem of the two partitions with certainty?

EDIT[1]
I add the output of the file -s command for a exfat partition and for an ext4 partition.

Output of file for exfat

> file -s /dev/sdf /dev/sdf: DOS/MBR boot sector

In this case exfat is not present in the output.

Output of file for ext4

file -s /dev/sdb1 /dev/sdb1: Linux rev 1.0 ext4 filesystem data, UUID=38bc3d5b-381e-4f19-8640-c77d9483882b (needs journal recovery) (extents) (64bit) (large files) (huge files)

In this case is present the info ext4 filesystem data,.

In these 4 examples (FAT32, NTFS, EXFAT, EXT4) the output of the file command appears very different for different filesystem types, so it is difficult to find a simple rule to decide the filesystem type by this output.

EDIT[2]
To clarify why I'm trying to use the file command to get information about the filesystem type of a USB, please read this post.

Improve this question
6
  • 1
    Why do you want to use file for this? As you show very nicely, it isn't the best tool for the job. Does this absolutely have to be done using file? There are several better options if file isn't a hard requirement. Also, what system(s) does this need to work on? Commented Apr 22 at 17:00
  • You could add the --keep-going option to your file command, or see man fdisk stat Commented Apr 22 at 19:46
  • You are mixing tests on full disks (/dev/sdb and /dev/sdf) and on partitions (/dev/sda1), is this intended? Commented Apr 23 at 10:08
  • @jcaron I have executed tests with different USB keys. These USB keys comes from my colleagues and they have been formatted by different system and operative system. It is not important if my kernel creates a /dev/sda or /dev/sda1 device for my goal. The answer of @terdon for me is perfect Commented Apr 23 at 10:15
  • 4
    You can't, because file is a tool for guessing. Commented Apr 23 at 13:21

3 Answers 3

Reset to default
15

In the specific case you show, it is relatively simple. Yes, FAT can appear in both, but NTFS only appears in one. So it is enough to do something simple like:

if file -s /dev/sda1 | grep -q NTFS ; then echo "Is NTFS" else echo "Is FAT32" fi

Of course, this has obvious limitations, including the fact that it will mark all non-NTFS partitions as FAT32. OK, so use a case statement instead:

file_output=$(file -s /dev/sda1); case "$file_output" in *NTFS*) echo "Is NTFS" ;; *FAT*) echo "Is FAT" ;; *) echo "I don't know what this thing is" esac

You can then easily add more conditions/cases.

This is all still very fragile though. Why not use something that reports the filesystem type directly instead? For instance, on a modern Linux system, you should have lsblk which, combined with -n (no headers) and -o FSTYPE, should return nothing but the file system type. On my system, for example, I have a single NVMe SSD with 6 partitions:

 $ lsblk -o NAME,FSTYPE NAME FSTYPE nvme0n1 ├─nvme0n1p1 vfat ├─nvme0n1p2 ├─nvme0n1p3 BitLocker ├─nvme0n1p4 ntfs ├─nvme0n1p5 ext4 ├─nvme0n1p6 crypto_LUKS │ └─home ext4 └─nvme0n1p7 swap

If I ask for a specific one:

$ lsblk -no FSTYPE /dev/nvme0n1p5 ext4

And if I want to see a FAT32 one:

$ lsblk -no FSTYPE /dev/nvme0n1p1 vfat

Compare to the far less immediately useful output of file (which, by the way, requires sudo unlike lsblk):

$ sudo file -s /dev/nvme0n1p1 | fold -sw 60 /dev/nvme0n1p1: DOS/MBR boot sector, code offset 0x58+2, OEM-ID "MSDOS5.0", sectors/cluster 8, reserved sectors 7166, Media descriptor 0xf8, sectors/track 63, heads 255, hidden sectors 2048, sectors 532480 (volumes > 32 MB), FAT (32 bit), sectors/FAT 513, serial number 0x6e5e90f0, label: "SYSTEM "

(I passed the above through fold only to avoid horizontal scrolling here.)

So, with lsblk in hand, all you need for the generic case is:

fstype=$(lsblk -no FSTYPE /dev/yourdevice)

You will then have the device's file system type in the $fstype variable.

Improve this answer
3
  • 1
    Agreed. Different Linux distros and different releases of the same distro can have different magic files/rules, making the file command questionable as a method to detect the filesystem on a partitioned device. And there are also the so-called "loop" devices with no partition on them, only a filesystem. Commented Apr 22 at 21:15
  • @terdon By your answer my problem is completely solved. Your code is now integrated in my script executed by a udev rule. The part of the script which contains your code is showed by this answer. Commented Apr 23 at 8:20
  • 1
    Note that there's nothing stopping a vfat FS to have NTFS in its label for instance (as in FROM NTFS-A or NOT NTFS) which would show up in the output of file Commented Apr 23 at 17:12
7

In the general case, it is impossible to assign a single, unique, filesystem type to a block device, for two reasons:

  • Some filesystems have multiple backwards-compatible versions: for example, ext4 is backwards-compatible with ext3, which is backwards-compatible with ext2. So, an ext2 filesystem is, at the same time, also a valid ext3 and ext4 filesystem.
  • You can create polyglot block devices, which contain data that is valid using multiple filesystems. It used to be quite common to create DVDs which were simultaneously valid ISO 9660, Joliet, UDF, and HFS+ filesystems.

How to determine, with certainty, the filesystem type of a partition from the outputs of the Linux "file -s" command?

Given the above, it is impossible to determine, with certainty, the filesystem type of a partition from the outputs of the Linux file -s command or any other command, because the the filesystem type of a partition is an undefined concept. A partition may contain multiple filesystems at the same time, or no filesystem at all.

Improve this answer
3
  • <github.com/meithecatte/cursedfs> is another example of a polyglot file system. Commented Apr 23 at 17:18
  • 1
    That's cool, although if I understand the README correctly, it is kind of cheating. It is not really a polyglot filesystem in the sense described above, but rather two filesystems coexisting on the same block device. But the two filesystems are independent, they don't share data. Polyglot filesystems like the hybrid DVDs of the 2000s have the different filesystem metadata point to the same data blocks, such that all filesystems contain the same data. But cursedfs is a cool concept nonetheless, and probably an even more relevant example, because depending on which filesystem you identify it as, Commented Apr 23 at 21:31
  • 1
    … it contains completely different data. Commented Apr 23 at 21:31
2

You’re using the wrong tool here, for a couple of reasons:

  • file is not an authoritative tool. It gives you it’s best guess, which may or may not be wrong, and may or may not be sufficiently specific even if it is correct. As an easy example, pointing it at a source file in a programming language it doesn’t know about (and even some it does if certain criteria are met) will usually just tell you that the file is a text file, the type of line endings, and possibly the encoding (if it’s an encoding that can be easily inferred, most can’t), which is ‘correct’, but usually not actually useful.
  • file is primarily a ‘people’ tool, not a ‘machine’ tool. It’s main purpose is to give the user a useful description, not to let a script figure out what a file is. This, in particular, means that it often gives all the information it can, which will sometimes not be useful. This is, in particular, what’s happening with the NTFS volume you ran it on, an NTFS volume actually has a (mostly valid) MBR at the start which is part of the format itself.

Instead, I would suggest using blkid on Linux. This command is part of util-linux and thus will be a part of the default install of almost all Linux distributions in existence (the only exceptions are the few rare distros that don’t use util-linux as part of their standard userspace). For your example, running blkid -o export /dev/sdX will spit out all the info it decodes about the volume in a format that is trivially imported into the shell’s environment. The specific key you care about here is TYPE, which will be the filesystem type of the device as most tools on Linux will see it (including, notably, the mount command when told to mount something without being told what filesystem type to use). It supports identifying almost all filesystems, partition tables, and other types of volume headers (including things like RAID array metadata) that you are likely to encounter on a Linux system, and it gives you a very succinct name that is easy to match on. And, despite the name, it also works just fine on disk images.

Alternatively, consider the disktype command, which you will usually need to install. It doesn’t support as many different filesystem/volume types as blkid and the output is not as easy to parse, but it includes support for some more exotic stuff like old Amiga filesystems or the original Mac filesystem (from before HFS was a thing).

Improve this answer
3
  • If you want, you can read this my post to know why I have decided to use the file command. In particular I have to use the file command only if the output of the command blkid -o udev /dev/sda1 is empty. For that question I have also written an answer. Commented Apr 23 at 21:19
  • @User051209 if blkid is empty, does lsblk work? I think lsblk uses the same interface as blkid but then also tries to guess, so kind of like file. Have you seen a case where lsblk fails and file works? Commented Apr 24 at 15:21
  • @terdon In this question I have written that both blkid -o udev /dev/sda1 and lsblk -n -o FSTYPE /dev/sda1 with my vfat USB key give an empty output; only file -s /dev/sda1 gives an useful, but complex output. Commented Apr 24 at 15:26

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.