Well what I meant was commit 80678bdd957cf49a9ccfc8b88ba3fb8b4c63fc12 makes gparted simply quit with error when trying to resize FAT, and commit 5adae27101565a5d6fed4aadf28ddb39872e41f5 fix that but introduced the issue I am reporting now. (Well actually, I CANNOT know exactly which of them introduced it.)
Well yeah dosfstools does not provide any resizing tool. Funny thing is not even Windows support FAT resizing in its disk management util (but it support that for NTFS). On 5 January 2016 at 01:56, Curtis Gedak <ged...@gmail.com> wrote: > Hi Brian, > > I agree that in an ideal world the code for resizing file systems would > exist in the file system project. Unfortunately this does not appear to > be the case for FAT16/FAT32 file systems. > > When I last looked there were no other free software or open source > options for resizing FAT16 and FAT32 file systems. The same goes for > the code in libparted that can shrink HFS and HFS+ file systems. > > Unless there is a change in this situation, I am in favour of keeping > the resizing code/library in parted. > > Regards, > Curtis Gedak > (Maintainer of GParted) > > On 16-01-04 10:45 AM, Brian C. Lane wrote: >> We should drop this resize code completely. I still think it was a >> mistake to revive it as a library. Filesystems should be managed by the >> upstream filesystem code, not parted.
