3 ms·
What FAT32 filesystem in the real world has a file named "foo.000.BigFAT" on it?
by NelsonMinar 4y ago
What FAT32 filesystem in the real world has a file named "foo.000.BigFAT" on it?
- londons_explore 4y agoI can imagine that if bigfat is successful, such files will start to exist. Imagine someone takes a bigfat drive and puts it in a non-bigfat capable machine, then zips up a directory and publishes it. When that directory is unzipped on a bigfat machine, should the bigfat files be re-joined, or should they show as separate files? One breaks the OS file API and the unzip program might crash/fail, while the other leads to the application trying to create filenames which can't exist in the filesystem.
- jonny_eh 4y ago> should the bigfat files be re-joined, or should they show as separate files They're only "rejoined" by the BigFAT compatible filesystem driver on access. By running such a driver, you're agreeing that such files should "appear" as one.
- mort96 4y agoHey, notice that you're suggesting that BigFAT should be disabled by default here; you think the user should have to choose to be running a driver with BigFAT-support. Maybe reflect on whether that's a desirable situation, or if it would've been preferable if the feature could've been enabled by default.
- mort96 4y agoSee my response to https://news.ycombinator.com/item?id=32753207 https://news.ycombinator.com/item?id=32753207. I'm not saying it will break everyone's FAT32 drives, but it is a breaking change in a filesystem, which seems like something kernel people would usually try to avoid.