whefs_fopen read only on a non existent file should fail

[GoogleCodeExporter]

What steps will reproduce the problem?
1. create a whefs file system
2. open a non existent file read only
3. note the lack of an error code.

What is the expected output? What do you see instead?

whefs_fopen read only on a non existent file should fail.

What version of the product are you using? On what operating system?

libwhefs-20100126
osx for the tools, embedding the library on android gingerbread with the r5 ndk.

Please provide any additional information below.

My work around is to wrap attempts to open read only files
with 

int rc = whefs_inode_by_name(fsys, szFilename, &n);
if (rc != 0) {
     fh = whefs_fopen(fsys,szFilename,"r");
}

Original issue reported on code.google.com by dan.schm...@gmail.com on 16 Apr 2011 at 8:23

[GoogleCodeExporter]

Good point. i _think_ this is fixed in the newer epfs code, but it will be easy 
to add this to whefs as well.

Thanks once again for taking the time to report the problem.

Original comment by sgbeal@googlemail.com on 18 Apr 2011 at 9:58

• Changed state: Accepted

[GoogleCodeExporter]

@Dan: i'm relatively certain, looking at the fopen code, that this was 
indirectly fixed by the issue #26 workaround. whefs_fopen_ro() (the internal 
impl for "r" open modes) searches by name and would have found the ghost entry 
from issue #26.

Can you verify that this is still a problem?

Original comment by sgbeal@googlemail.com on 18 Apr 2011 at 2:07

[GoogleCodeExporter]

i just tested this with the following additions to the issue-26.c code attached 
to issue #26:

{ /* test issue #25 while we're at it ... */
        fileptr = whefs_fopen( fsys, "non-existent", "r" );
        assert( NULL == fileptr );

        rc = whefs_unlink_filename(fsys,"testf");
        assert( 0 == rc );

        fileptr = whefs_fopen( fsys, "testf", "r" );
        assert( NULL == fileptr );
}

and the problem appears to be solved. i believe this was a side-effect of issue 
#26, where fopen() was succeeding but returning an inode which was marked as 
unused (which could have all kinds of nasty side-effects later on, depending on 
app usage).

@Dan: if you're still seeing this let me know and i'll re-open this ticket.

Original comment by sgbeal@googlemail.com on 18 Apr 2011 at 4:54

• Changed state: Fixed