similar to: [PATCH 0/5] fix installer issues and enable some MSVC compatibility

On Thu, Feb 25, 2016 at 7:59 PM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > Hi Ady, > > Your insightful post prompted me to to a little bit more digging as to how > the Ridgecrop algorithm computed its FAT size, with the result of my > investigations presented below. > > NB: For those who don't want to go through this whole part, there's a TL;DR

> 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 >

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 --------------

> 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 > The expression: "...as there is an extra sector being

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

In the following text, I am about to use terms such as "inaccurate". I don't mean to question what some code does, but rather to compare the expressions against what I think is a more accurate one, in theory. I mean no disrespect, and I am not saying that developers are doing the wrong thing. In addition, of course I could be wrong (or type in incorrectly, or some formatting

I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and while I could see that this #define was introduced in e4fc44 [1], but the reason to introduce it is not mentioned, and I can't really see a good reason to have it, especially as MSVC will happily compile that source. So far I have found no evidence that _GNU_SOURCE applies to memset/memmove/memcpy, which are the

If the ldlinux being processed is garbage, the search for LDLINUX_MAGIC will overflow its buffer - fix that. I did encounter this issue in Rufus as, due to notorious incompatibilities between different versions of ldlinux.sys and the com32's residing on an ISO, we download a version specific ldlinux.sys from our server... which may get trashed if the user sits behind one of these

Hi Ady, Your insightful post prompted me to to a little bit more digging as to how the Ridgecrop algorithm computed its FAT size, with the result of my investigations presented below. NB: For those who don't want to go through this whole part, there's a TL;DR near the end. For reference, the computation of the FAT size all done in the GetFATSizeSectors(), the code of which is at [1]

On 2/24/2016 08:02, Pete Batard via Syslinux wrote: > If the ldlinux being processed is garbage, the search for > LDLINUX_MAGIC will overflow its buffer - fix that. > I did encounter this issue in Rufus as, due to notorious > incompatibilities between different versions of ldlinux.sys and the > com32's residing on an ISO, we download a version specific ldlinux.sys > from

On Wed, Feb 24, 2016 at 8:02 AM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > I get a redefinition warning on _GNU_SOURCE when compiling with MinGW, and > while I could see that this #define was introduced in e4fc44 [1], but the > reason to introduce it is not mentioned, and I can't really see a good > reason to have it, especially as MSVC will happily compile

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 >>

More MSVC compatibility fixes, for packed structures. NB: In case you are aware of the issues that may come with MS vs GCC packing, so far, I have not seen evidence of detrimental impact from using ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for MinGW), with regards to the sections of code I am using in Rufus. -------------- next part --------------

On 2/24/2016 08:02, Pete Batard via Syslinux wrote: > The variable 'ok' is never used and generates a warning. Remove it. Also > ntfssect.c is designed to be compiled in non Unicode mode when using > MSVC compilers, so remove all ambiguity about it (LPCTSTR -> LPCSTR, use > of 'A' API calls) so that it doesn't break when compiled in Unicode > mode, which is

On Wed, Feb 24, 2016 at 8:02 AM, Pete Batard via Syslinux <syslinux at zytor.com> wrote: > More MSVC compatibility fixes, for packed structures. > NB: In case you are aware of the issues that may come with MS vs GCC > packing, so far, I have not seen evidence of detrimental impact from using > ms_struct packing in MSVC (vs gcc_struct, which is explicitly specified for >

On 2016.02.26 15:32, Ady via Syslinux wrote: > Regarding the "+1", when talking about the math (not the computer code > to achieve a result as accurate as it can be) Well, sorry, but I will not dissociate the context of application from the formula itself. I thought this was implied into what I wrote, which was in the context of fixing a computation algorithm bug. The sole

Hi Ady, I won't comment on the reasons why the original computation was wrong, but thanks for the detailed analysis. On 2016.02.26 08:05, Ady via Syslinux wrote: >> Thus we can finally get a formula for Fs that satisfies the above: >> >> Fs = (To - Rs + Nf * Cs) / ((Ss * Cs / Fe) + Nf) + 1 > > I believe such formula is slightly inaccurate too. > > My

Hi Gene, On 2016.02.26 11:49, Gene Cumm wrote: > I think there may be another answer to this: > > 1) a tool to fix the broken FSs by "wasting" the high clusters of the > file system, a non-destructive correction. As it stands they're > effectively wasted already and might risk a user thinking the file > system isn't full when in fact the FAT itself is.

This is the initial NTFS file system support for Syslinux :-) The following changes since commit 67954e370003d9bbfd8b58042669f2e9d532636f: ifmemdsk: remove spurious +x bit (2011-08-25 10:58:44 -0700) are available in the git repository at: git://github.com/pcacjr/syslinux.git ntfs-for-hpa Paulo Alcantara (34): Add NTFS filesystem support to Linux and Windows installers Initial

> > instead of _always_ adding "+1" (which would be > > incorrect and inefficient from the point of view of the resulting > > allocatable size). > > I carefully considered this, and I dispute the fact that this is incorrect. > (snip) > Still, I won't prevent you (or anybody else interested) to provide a > proper formula if you want. ;) >