search for: fat32format

When trying to installing Syslinux on a FAT32 drive formatted using Ridgecrop's Large FAT32 formatting tool [1], the installer will bail due to the minfatsize check, as there is an extra sector being used. This fix addresses that. [1] http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm -------------- next part --------------

...to installing Syslinux on a FAT32 drive formatted using > Ridgecrop's Large FAT32 formatting tool [1], the installer will bail due > to the minfatsize check, as there is an extra sector being used. This > fix addresses that. > > [1] http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm > The expression: "...as there is an extra sector being used." is not clear (to me). There is an "extra" sector, in comparison to... what exactly? For instance... Are there other formatting tools (in whichever OS) that are capable of similar "large" FAT32...

...t; > This being said, and to address Ady's subsequent point: > > While I can now address the issue in Rufus (and will contact Tom Thornhill > of Ridgecrop to let him know about both the issue & fix), I suspect there > are users out there who are using and will continue to use fat32format.exe > with the bad computation algorithm, as well as other developers who might > lift the existing Large FAT32 format code without realizing that doing so > will break Syslinux installation. So it may still be worth relaxing the > check especially if, as Ady pointed out, not having all...

...e impacted. Besides, for obvious compatibility reasons, I would advocate using -D_GNU_SOURCE as a compiler option if one really needs it, rather than have it in a source. Regards, /Pete [1] https://github.com/pbatard/rufus/tree/master/src/syslinux [2] http://www.ridgecrop.demon.co.uk/index.htm?fat32format.htm [3] http://rufus.akeo.ie/files/syslinux-6.03/ [4] https://github.com/geneC/syslinux/commit/e4fc443f9b70f188963ff33e0a16ccb72a553540

On 02/26/16 09:54, Gene Cumm via Syslinux wrote: >> >> I'm not exactly sure how that would work (how would you mark those clusters >> as wasted when my understanding is that the FAT's can't provide any >> knowledge about them in the first place?) and unless it is automatically >> integrated and ran during the Syslinux installation, it sounds quite >>

...is no longer an issue. This being said, and to address Ady's subsequent point: While I can now address the issue in Rufus (and will contact Tom Thornhill of Ridgecrop to let him know about both the issue & fix), I suspect there are users out there who are using and will continue to use fat32format.exe with the bad computation algorithm, as well as other developers who might lift the existing Large FAT32 format code without realizing that doing so will break Syslinux installation. So it may still be worth relaxing the check especially if, as Ady pointed out, not having all sectors address...

...his being said, and to address Ady's subsequent point: > > While I can now address the issue in Rufus (and will contact Tom > Thornhill of Ridgecrop to let him know about both the issue & fix), I > suspect there are users out there who are using and will continue to use > fat32format.exe with the bad computation algorithm, as well as other > developers who might lift the existing Large FAT32 format code without > realizing that doing so will break Syslinux installation. So it may > still be worth relaxing the check especially if, as Ady pointed out, not > having...

Hello, I have a dual boot with Windows 7 64 bit enterprise edition and Opensolaris build 134. This is on Sun Ultra 40 M1 workstation. Three hard drives, 2 in ZFS mirror, 1 is shared with Windows. Last 2 days I was working in Windows. I didn''t touch the hard drives in any way except I once opened Disk Management to figure out why a external USB hard drive is not being listed.

Hi Ady, On 2016.02.25 02:08, Ady via Syslinux wrote: > There is an "extra" sector, in comparison to... what exactly? Sorry if I wasn't clear. I think I implied that the Large FAT32 fat size had an extra sector compared to minfatsize, when of course I meant the opposite (the Large FAT32 has one less sector than the minfatsize computed by the unpatched code, hence the check