headers
James Paige | 1 Jun 2012 01:01
Favicon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On Thu, May 31, 2012 at 11:23:40AM -0700, James Paige wrote:
> On Thu, May 31, 2012 at 09:46:46AM -0700, James Paige wrote:
> > On Thu, May 31, 2012 at 09:34:19AM -0700, James Paige wrote:
> > > On Mon, May 21, 2012 at 03:23:39PM -0700, James Paige wrote:
> > > > I was messing around with trying to make a simplified test case for the 
> > > > LOF bug. I never did figure out exactly what to type to compile a simple 
> > > > .bas file, but I discovered it was easy to just add another compile 
> > > > target to SConscript using relump and unlump as my model.
> > > > 
> > > > I couldn't reproduce any oddness with LOF, but I did discover some 
> > > > peculiar behavior when a file is opened BINARY ACCESS READ
> > > > 
> > > > The following code works perfectly on Linux, but on Mac, it fails to 
> > > > read anything at all from the first two files. The third and fourth file 
> > > > work fine.
> > > > 
> > > > If you change
> > > > - OPEN filename FOR BINARY ACCESS READ AS #fh
> > > > + OPEN filename FOR BINARY AS #fh
> > > > Then the code works perfectly on Mac.
> > > > 
> > > > ------------------------------------------------------
> > > > 
> > > > SUB test(filename as string)
> > > >  DIM size as integer
> > > >  DIM chunk as string = STRING(10, 0)
> > > > 
> > > >  DIM fh as integer = FREEFILE
> > > > 
> > > >  OPEN filename FOR BINARY ACCESS READ AS #fh
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Paige | 1 Jun 2012 22:39
Favicon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On Thu, May 31, 2012 at 11:23:40AM -0700, James Paige wrote:
> On Thu, May 31, 2012 at 09:46:46AM -0700, James Paige wrote:
> > On Thu, May 31, 2012 at 09:34:19AM -0700, James Paige wrote:
> > > On Mon, May 21, 2012 at 03:23:39PM -0700, James Paige wrote:
> > > > I was messing around with trying to make a simplified test case for the 
> > > > LOF bug. I never did figure out exactly what to type to compile a simple 
> > > > .bas file, but I discovered it was easy to just add another compile 
> > > > target to SConscript using relump and unlump as my model.
> > > > 
> > > > I couldn't reproduce any oddness with LOF, but I did discover some 
> > > > peculiar behavior when a file is opened BINARY ACCESS READ
> > > > 
> > > > The following code works perfectly on Linux, but on Mac, it fails to 
> > > > read anything at all from the first two files. The third and fourth file 
> > > > work fine.
> > > > 
> > > > If you change
> > > > - OPEN filename FOR BINARY ACCESS READ AS #fh
> > > > + OPEN filename FOR BINARY AS #fh
> > > > Then the code works perfectly on Mac.
> > > > 
> > > > ------------------------------------------------------
> > > > 
> > > > SUB test(filename as string)
> > > >  DIM size as integer
> > > >  DIM chunk as string = STRING(10, 0)
> > > > 
> > > >  DIM fh as integer = FREEFILE
> > > > 
> > > >  OPEN filename FOR BINARY ACCESS READ AS #fh
(Continue reading)

Permalink | Reply | 10 comments |
headers
subversion | 1 Jun 2012 22:45
Favicon

SVN: james/5202 Tweaking the test.bas for the Mac OPEN bug

james
2012-06-01 13:45:24 -0700 (Fri, 01 Jun 2012)
43
Tweaking the test.bas for the Mac OPEN bug
---
U   wip/test.bas
Permalink | Reply | 0 comments |
headers
subversion | 1 Jun 2012 22:57
Favicon

SVN: james/5203 Mac OPEN bug testcase explicitly check the return value of the OPEN comm

james
2012-06-01 13:57:48 -0700 (Fri, 01 Jun 2012)
96
Mac OPEN bug testcase explicitly check the return value of the OPEN command for success/failure
---
U   wip/test.bas
Permalink | Reply | 0 comments |
headers
James Paige | 1 Jun 2012 23:13
Favicon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On Fri, Jun 01, 2012 at 01:39:48PM -0700, James Paige wrote:
> On Thu, May 31, 2012 at 11:23:40AM -0700, James Paige wrote:
> > On Thu, May 31, 2012 at 09:46:46AM -0700, James Paige wrote:
> > > On Thu, May 31, 2012 at 09:34:19AM -0700, James Paige wrote:
> > > > On Mon, May 21, 2012 at 03:23:39PM -0700, James Paige wrote:
> > > > > I was messing around with trying to make a simplified test case for the 
> > > > > LOF bug. I never did figure out exactly what to type to compile a simple 
> > > > > .bas file, but I discovered it was easy to just add another compile 
> > > > > target to SConscript using relump and unlump as my model.
> > > > > 
> > > > > I couldn't reproduce any oddness with LOF, but I did discover some 
> > > > > peculiar behavior when a file is opened BINARY ACCESS READ
> > > > > 
> > > > > The following code works perfectly on Linux, but on Mac, it fails to 
> > > > > read anything at all from the first two files. The third and fourth file 
> > > > > work fine.
> > > > > 
> > > > > If you change
> > > > > - OPEN filename FOR BINARY ACCESS READ AS #fh
> > > > > + OPEN filename FOR BINARY AS #fh
> > > > > Then the code works perfectly on Mac.
> > > > > 
> > > > > ------------------------------------------------------
> > > > > 
> > > > > SUB test(filename as string)
> > > > >  DIM size as integer
> > > > >  DIM chunk as string = STRING(10, 0)
> > > > > 
> > > > >  DIM fh as integer = FREEFILE
> > > > >
(Continue reading)

Permalink | Reply | 9 comments |
headers
David Gowers (kampu | 2 Jun 2012 09:25
Picon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On Sat, Jun 2, 2012 at 6:43 AM, James Paige <Bob <at> hamsterrepublic.com> wrote:
>> Actually, I can't believe I missed this before, but it looks like ALL
>> files < 4096 bytes are affected. The filenames that have smaller sizes
>> that were not affected were actually the names of directories.
>>
>> I am not sure why OPEN works at all on directories, but it does. The LOF
>> when opening a directory appears to be nonsense.
>>
>
> When using the Linux version of FreeBasic, you can always successfully
> OPEN directories, and LOF is always 4096.

This is rather academic, but.. is that true even for directories that
aren't 4096 bytes in size (which is the default size for ext*) ?

( after running the following code in a Python shell,:

---

import os

def spamfiles (directory, nfiles = 256):
    try:
        os.mkdir(directory)
    except:
        pass
    for i in range (nfiles):
        f = open(os.path.join(directory, str(i)), 'wb')
        f.write (b'\x00')
        f.close()
(Continue reading)

Permalink | Reply | 8 comments |
headers
Ralph Versteegen | 2 Jun 2012 11:45
Picon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On 2 June 2012 19:25, David Gowers (kampu) <00ai99 <at> gmail.com> wrote:
> On Sat, Jun 2, 2012 at 6:43 AM, James Paige <Bob <at> hamsterrepublic.com> wrote:
>>> Actually, I can't believe I missed this before, but it looks like ALL
>>> files < 4096 bytes are affected. The filenames that have smaller sizes
>>> that were not affected were actually the names of directories.
>>>
>>> I am not sure why OPEN works at all on directories, but it does. The LOF
>>> when opening a directory appears to be nonsense.
>>>
>>
>> When using the Linux version of FreeBasic, you can always successfully
>> OPEN directories, and LOF is always 4096.
>
> This is rather academic, but.. is that true even for directories that
> aren't 4096 bytes in size (which is the default size for ext*) ?
>
> ( after running the following code in a Python shell,:
>
> ---
>
> import os
>
> def spamfiles (directory, nfiles = 256):
>    try:
>        os.mkdir(directory)
>    except:
>        pass
>    for i in range (nfiles):
>        f = open(os.path.join(directory, str(i)), 'wb')
>        f.write (b'\x00')
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Paige | 2 Jun 2012 19:04
Favicon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On Sat, Jun 02, 2012 at 04:55:12PM +0930, David Gowers (kampu) wrote:
> On Sat, Jun 2, 2012 at 6:43 AM, James Paige <Bob <at> hamsterrepublic.com> wrote:
> >> Actually, I can't believe I missed this before, but it looks like ALL
> >> files < 4096 bytes are affected. The filenames that have smaller sizes
> >> that were not affected were actually the names of directories.
> >>
> >> I am not sure why OPEN works at all on directories, but it does. The LOF
> >> when opening a directory appears to be nonsense.
> >>
> >
> > When using the Linux version of FreeBasic, you can always successfully
> > OPEN directories, and LOF is always 4096.
> 
> This is rather academic, but.. is that true even for directories that
> aren't 4096 bytes in size (which is the default size for ext*) ?

Ah, yes, you are right. Some directories return other sizes.

> ---
> 
> you can type in, for example, "spamfiles ('/tmp/foo8')" which creates
> a directory with 256 files inside. ('ls' tells me that this directory
> is 5160 bytes. larger nfiles produce larger directory size, for
> example 512 makes the directory 10280 bytes, 1024 -> 20520)
> 
> 
> SHORT VERSION: I suspect FreeBasic is just returning the actual
> directory size, which may vary according to the number of items
> inside. I guess the only alternative behaviour they could have chosen
> here is to return an invalid value like -1 for directories. But then
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Paige | 2 Jun 2012 19:28
Favicon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On Sat, Jun 02, 2012 at 09:45:55PM +1200, Ralph Versteegen wrote:
> On 2 June 2012 19:25, David Gowers (kampu) <00ai99 <at> gmail.com> wrote:
> > On Sat, Jun 2, 2012 at 6:43 AM, James Paige <Bob <at> hamsterrepublic.com> wrote:
> >>> Actually, I can't believe I missed this before, but it looks like ALL
> >>> files < 4096 bytes are affected. The filenames that have smaller sizes
> >>> that were not affected were actually the names of directories.
> >>>
> >>> I am not sure why OPEN works at all on directories, but it does. The LOF
> >>> when opening a directory appears to be nonsense.
> >>>
> >>
> >> When using the Linux version of FreeBasic, you can always successfully
> >> OPEN directories, and LOF is always 4096.
> >
> > This is rather academic, but.. is that true even for directories that
> > aren't 4096 bytes in size (which is the default size for ext*) ?
> >
> > ( after running the following code in a Python shell,:
> >
> > ---
> >
> > import os
> >
> > def spamfiles (directory, nfiles = 256):
> >    try:
> >        os.mkdir(directory)
> >    except:
> >        pass
> >    for i in range (nfiles):
> >        f = open(os.path.join(directory, str(i)), 'wb')
(Continue reading)

Permalink | Reply | 4 comments |
headers
Ralph Versteegen | 2 Jun 2012 19:40
Picon

Re: Mac bug: Maybe BINARY ACCESS READ rather than LOF is the culprit?

On 3 June 2012 05:28, James Paige <Bob <at> hamsterrepublic.com> wrote:
> On Sat, Jun 02, 2012 at 09:45:55PM +1200, Ralph Versteegen wrote:
>> On 2 June 2012 19:25, David Gowers (kampu) <00ai99 <at> gmail.com> wrote:
>> > On Sat, Jun 2, 2012 at 6:43 AM, James Paige <Bob <at> hamsterrepublic.com> wrote:
>> >>> Actually, I can't believe I missed this before, but it looks like ALL
>> >>> files < 4096 bytes are affected. The filenames that have smaller sizes
>> >>> that were not affected were actually the names of directories.
>> >>>
>> >>> I am not sure why OPEN works at all on directories, but it does. The LOF
>> >>> when opening a directory appears to be nonsense.
>> >>>
>> >>
>> >> When using the Linux version of FreeBasic, you can always successfully
>> >> OPEN directories, and LOF is always 4096.
>> >
>> > This is rather academic, but.. is that true even for directories that
>> > aren't 4096 bytes in size (which is the default size for ext*) ?
>> >
>> > ( after running the following code in a Python shell,:
>> >
>> > ---
>> >
>> > import os
>> >
>> > def spamfiles (directory, nfiles = 256):
>> >    try:
>> >        os.mkdir(directory)
>> >    except:
>> >        pass
>> >    for i in range (nfiles):
(Continue reading)

Permalink | Reply | 3 comments |

Gmane