5 ms·

For anyone looking to learn a bit more about filesystems ext2 strikes a great balance of simplicity and real world practicality, making it good to learn from. C

For anyone looking to learn a bit more about filesystems ext2 strikes a great balance of simplicity and real world practicality, making it good to learn from. Code here https://elixir.bootlin.com/linux/v3.9/source/fs/ext2 https://elixir.bootlin.com/linux/v3.9/source/fs/ext2

gertop 3y ago
Seems to me like either exFat or FAT32 would be simpler? There's billions of devices using it with millions more sold every year, and it's supported by all operating systems in current use so it also has greater real world practicality.
- userbinator 3y ago
  FAT is definitely far more portable; exFAT, not so much.
  - deleted 3y ago
    [deleted]
  - bbatha 3y ago
    exFAT is pretty portable these days and not encumbered by annoying file and disk size limitations. Its the default for SD cards and has had native support in Macos and windows for 15 years, linux has had kernel drivers for 5 years and FUSE/3rd party kernel modules for longer. Unless you need to interface with an ancient system there's no reason to use FAT on portable drives anymore.
    - G3rn0ti 3y ago
      I had trouble booting the Windows 10 installer from an exFAT formatted usb drive. That was thee years ago. So back then I had to recompress a cab file to make it smaller than 4GB using Linux. It worked but I was scratching my head that this was an issue.
      - opan 3y ago
        I thought Windows install drives used NTFS.
        G3rn0ti 3y ago
        I guess this could work but all instructions I could find back then were saying to create a FAT32 file system. I switched to exFAT after finding some installation files being large than 4GB. But then the stupid thing would not boot. So I managed to re-compress the largest cab file and got it below 4GB. Edit: But I am not sure an NTFS formatted stick is actually UEFI-bootable.
        userbinator 3y ago
        UEFI is only specified to boot from FAT32, but apparently some BIOSes have included an NTFS driver: https://superuser.com/questions/588080/uefi-boot-a-ntfs-drive https://superuser.com/questions/588080/uefi-boot-a-ntfs-driv... https://superuser.com/questions/1234496/windows-10-efi-folder-is-located-on-ntfs-c-drive-how-is-this-possible https://superuser.com/questions/1234496/windows-10-efi-folde... The other notable exception I knew of from before was Apple's UEFI had HFS+ support (and loads the boot file from its own nonstandard location.)
        justsomehnguy 3y ago
        > But I am not sure an NTFS formatted stick is actually UEFI-bootable. Practically - no. But you can make a FAT32 standard bootable thumb drive, without install.wim which is > 4GB, make a second partition on that drive and format it NTFS, place everything (including install.wim) there and launch it from there after WinPE would run from the first partition.
        wolfhumble 3y ago
        > launch it from there after WinPE would run from the first partition. How would you launch it from the NTFS partition; is that an option while in WinPE or will Windows automatically look for install.wim on other partitions? (met the 4GB problem in FAT32 and split install.wim in two for a successful USB install drive, but it would be interesting to learn how to do this via NFTS). Thanks!
    - deknos 3y ago
      but it's encumbered by patents of microsoft. BSDs or Reactos or minix are not allowed to implement it and distribute it freely. only linux got a free pass from microsoft as they use it. F** Microsoft and EXFat as long it's not freely implementable and distributable with free or open software.
      - deleted 3y ago
        [deleted]
      - fragmede 3y ago
        https://www.micski.dk/2021/04/10/how-to-mount-exfat-formatted-sd-memory-card-on-freebsd/ https://www.micski.dk/2021/04/10/how-to-mount-exfat-formatte... makes no mention of distribution issues. can you elaborate?
        lexlash 3y ago
        Your link discusses how to install fusefs-exfat, which is a separate package, which is what all Linux distributions did before the 2019 licensing - Android had a separate licensed kernel module, etc. I can’t speak to the current state of BSD but a cursory search yields a lot of discussion. Regarding the encumbrances in general, https://en.wikipedia.org/wiki/ExFAT https://en.wikipedia.org/wiki/ExFAT covers this, notably: > Companies can integrate exFAT into a specific group of consumer devices, including cameras, camcorders, and digital photo frames for a flat fee. Mobile phones, PCs, and networks have a different volume pricing model. > exFAT is the official file system of SDXC cards. Because of this, any device not supporting exFAT, such as the Nintendo 3DS, may not legally advertise itself as SDXC compatible, despite supporting SDXC cards as mass storage devices by formatting the card with FAT32 or a proprietary file system tied to the device in question. > On 28 August 2019, Microsoft published the exFAT specification and released the patent to the Open Invention Network members. The Linux kernel introduced native exFAT support with the 5.4 release in November 2019. So yes, this has been annoying for years (2006-2019, at a minimum) and left a very bad taste in my mouth as someone who has a few dozen SD cards that regularly move around various embedded devices that are expensive, rarely receive updates, and work just fine (e.g. 3d printers, digital frames, regular printers, local storage on security cameras, adapters for retro hardware, etc.). The Wikipedia article notes that the Nintendo 3DS - 75.94 million units sold during its 2011-2019 lifespan [1] - lacked exFAT support, so it’s not like this only affected low-end/cheap/uncommon devices from small companies. Windows “helpfully” disabled all ways to format large SD cards as FAT32 so I end up having to rely on a third party tool. Of course, whenever possible, I use a sane and journaled filesystem but it’s rare that I have a choice. :) [1] Numbers sourced from https://en.wikipedia.org/wiki/Nintendo_3DS https://en.wikipedia.org/wiki/Nintendo_3DS
- NavinF 3y ago
  Those filesystems also don't trust their input and check bounds correctly. Mounting a malicious ext* partition can trigger code execution so it's never auto mounted and shouldn't be used on removable drives. This is a really weird limitation that the other common file systems don't have
  - chungy 3y ago
    Not sure what system you've used, but I've never seen automounting fail to work on ext4 volumes. That being said, basically every file system ever is vulnerable to the malicious image. Kernel drivers assume that the metadata is sane enough and mistakes are from simple bugs, not deliberate attacks.
    - NavinF 3y ago
      I never said it would fail to work, I said it's a massive vulnerability. And no, implementations of other filesystems like FAT32 and ISO 9660 consider it a security bug when a malicious image gains arbitrarily code execution. What you described is exclusively a Linux desktop problem
  - JackSlateur 3y ago
    This is true for virtually all filesystems From the kernel point of view, the filesystem code runs in kernel mode and expects a trusted block device Some people (from gnome etc) do auto-mount filesystems, which is a crazy idea and they know it but they do not care https://lwn.net/Articles/951846/ https://lwn.net/Articles/951846/
    - Zambyte 3y ago
      Maybe GNOME is just designed with great anticipation for GNU Hurd :-D
    - uuddlrlrbaba 3y ago
      Considering auto mount is now built into systemd I'd say its not such a crazy idea after all
- Dwedit 3y ago
  FAT16/FAT32 is what you use when you want all your files to suddenly become 32768 bytes large instead of their actual file size (true story). More specifically, the cluster chain got overwritten with junk data, so all files got truncated down to one cluster in length. This is why metadata Journalling exists for file systems.

gertop 3y ago

Seems to me like either exFat or FAT32 would be simpler? There's billions of devices using it with millions more sold every year, and it's supported by all operating systems in current use so it also has greater real world practicality.

userbinator 3y ago
FAT is definitely far more portable; exFAT, not so much.
- deleted 3y ago
  [deleted]
- bbatha 3y ago
  exFAT is pretty portable these days and not encumbered by annoying file and disk size limitations. Its the default for SD cards and has had native support in Macos and windows for 15 years, linux has had kernel drivers for 5 years and FUSE/3rd party kernel modules for longer. Unless you need to interface with an ancient system there's no reason to use FAT on portable drives anymore.
  - G3rn0ti 3y ago
    I had trouble booting the Windows 10 installer from an exFAT formatted usb drive. That was thee years ago. So back then I had to recompress a cab file to make it smaller than 4GB using Linux. It worked but I was scratching my head that this was an issue.
    - opan 3y ago
      I thought Windows install drives used NTFS.
      - G3rn0ti 3y ago
        I guess this could work but all instructions I could find back then were saying to create a FAT32 file system. I switched to exFAT after finding some installation files being large than 4GB. But then the stupid thing would not boot. So I managed to re-compress the largest cab file and got it below 4GB. Edit: But I am not sure an NTFS formatted stick is actually UEFI-bootable.
        userbinator 3y ago
        UEFI is only specified to boot from FAT32, but apparently some BIOSes have included an NTFS driver: https://superuser.com/questions/588080/uefi-boot-a-ntfs-drive https://superuser.com/questions/588080/uefi-boot-a-ntfs-driv... https://superuser.com/questions/1234496/windows-10-efi-folder-is-located-on-ntfs-c-drive-how-is-this-possible https://superuser.com/questions/1234496/windows-10-efi-folde... The other notable exception I knew of from before was Apple's UEFI had HFS+ support (and loads the boot file from its own nonstandard location.)
        justsomehnguy 3y ago
        > But I am not sure an NTFS formatted stick is actually UEFI-bootable. Practically - no. But you can make a FAT32 standard bootable thumb drive, without install.wim which is > 4GB, make a second partition on that drive and format it NTFS, place everything (including install.wim) there and launch it from there after WinPE would run from the first partition.
        wolfhumble 3y ago
        > launch it from there after WinPE would run from the first partition. How would you launch it from the NTFS partition; is that an option while in WinPE or will Windows automatically look for install.wim on other partitions? (met the 4GB problem in FAT32 and split install.wim in two for a successful USB install drive, but it would be interesting to learn how to do this via NFTS). Thanks!
  - deknos 3y ago
    but it's encumbered by patents of microsoft. BSDs or Reactos or minix are not allowed to implement it and distribute it freely. only linux got a free pass from microsoft as they use it. F** Microsoft and EXFat as long it's not freely implementable and distributable with free or open software.
    - deleted 3y ago
      [deleted]
    - fragmede 3y ago
      https://www.micski.dk/2021/04/10/how-to-mount-exfat-formatted-sd-memory-card-on-freebsd/ https://www.micski.dk/2021/04/10/how-to-mount-exfat-formatte... makes no mention of distribution issues. can you elaborate?
      - lexlash 3y ago
        Your link discusses how to install fusefs-exfat, which is a separate package, which is what all Linux distributions did before the 2019 licensing - Android had a separate licensed kernel module, etc. I can’t speak to the current state of BSD but a cursory search yields a lot of discussion. Regarding the encumbrances in general, https://en.wikipedia.org/wiki/ExFAT https://en.wikipedia.org/wiki/ExFAT covers this, notably: > Companies can integrate exFAT into a specific group of consumer devices, including cameras, camcorders, and digital photo frames for a flat fee. Mobile phones, PCs, and networks have a different volume pricing model. > exFAT is the official file system of SDXC cards. Because of this, any device not supporting exFAT, such as the Nintendo 3DS, may not legally advertise itself as SDXC compatible, despite supporting SDXC cards as mass storage devices by formatting the card with FAT32 or a proprietary file system tied to the device in question. > On 28 August 2019, Microsoft published the exFAT specification and released the patent to the Open Invention Network members. The Linux kernel introduced native exFAT support with the 5.4 release in November 2019. So yes, this has been annoying for years (2006-2019, at a minimum) and left a very bad taste in my mouth as someone who has a few dozen SD cards that regularly move around various embedded devices that are expensive, rarely receive updates, and work just fine (e.g. 3d printers, digital frames, regular printers, local storage on security cameras, adapters for retro hardware, etc.). The Wikipedia article notes that the Nintendo 3DS - 75.94 million units sold during its 2011-2019 lifespan [1] - lacked exFAT support, so it’s not like this only affected low-end/cheap/uncommon devices from small companies. Windows “helpfully” disabled all ways to format large SD cards as FAT32 so I end up having to rely on a third party tool. Of course, whenever possible, I use a sane and journaled filesystem but it’s rare that I have a choice. :) [1] Numbers sourced from https://en.wikipedia.org/wiki/Nintendo_3DS https://en.wikipedia.org/wiki/Nintendo_3DS
NavinF 3y ago
Those filesystems also don't trust their input and check bounds correctly. Mounting a malicious ext* partition can trigger code execution so it's never auto mounted and shouldn't be used on removable drives. This is a really weird limitation that the other common file systems don't have
- chungy 3y ago
  Not sure what system you've used, but I've never seen automounting fail to work on ext4 volumes. That being said, basically every file system ever is vulnerable to the malicious image. Kernel drivers assume that the metadata is sane enough and mistakes are from simple bugs, not deliberate attacks.
  - NavinF 3y ago
    I never said it would fail to work, I said it's a massive vulnerability. And no, implementations of other filesystems like FAT32 and ISO 9660 consider it a security bug when a malicious image gains arbitrarily code execution. What you described is exclusively a Linux desktop problem
- JackSlateur 3y ago
  This is true for virtually all filesystems From the kernel point of view, the filesystem code runs in kernel mode and expects a trusted block device Some people (from gnome etc) do auto-mount filesystems, which is a crazy idea and they know it but they do not care https://lwn.net/Articles/951846/ https://lwn.net/Articles/951846/
  - Zambyte 3y ago
    Maybe GNOME is just designed with great anticipation for GNU Hurd :-D
  - uuddlrlrbaba 3y ago
    Considering auto mount is now built into systemd I'd say its not such a crazy idea after all
Dwedit 3y ago
FAT16/FAT32 is what you use when you want all your files to suddenly become 32768 bytes large instead of their actual file size (true story). More specifically, the cluster chain got overwritten with junk data, so all files got truncated down to one cluster in length. This is why metadata Journalling exists for file systems.