Forums | developer.brewmp.com Forums | developer.brewmp.com

Developer

Forums

Forums:

I am going crazy with this - it just stopped working and it is so basic ...

I have characters in the buf, it always returns 0 bytes writtem and in checking GetLastError it returns 0 - so no error. So, why are 0 bytes being written?? Strange behaviour or have I stuffed up on something obvious???

I have :

result = IFILEMGR_Test( _file_mgr, GGC_LOG_FILE );
if ( SUCCESS == result )
{
log_file = fileOpen(_OFM_APPEND );
if ( !log_file )
return EFAILED;

} else {
log_file = fileOpen(_OFM_CREATE );
if ( !log_file )
return EFAILED;

// write timestamp to file
JulianType jt;
char timestamp[30];

GETJULIANDATE(GETTIMESECONDS(), &jt);
SPRINTF(timestamp, "[%04d-%02d-%02d %02d:%02d:%02d] ", jt.wYear, jt.wMonth, jt.wDay,
jt.wHour, jt.wMinute,jt.wSecond);

fileWrite(log_file , timestamp, STRLEN(timestamp));

// write message to file

fileWrite(log_file , message, STRLEN(message));
fileWrite(log_file , GGC_END_LINE, STRLEN(GGC_END_LINE));

and my methods:

uint32 GGC::fileWrite(IFile* file, PACKED const void* buf, uint32 count)
{
uint32 num_bytes = IFILE_Write(file , buf, count);

int retval = checkFileError();

return num_bytes;

int GGC::checkFileError()
{
int retval;

switch (retval = IFILEMGR_GetLastError(_file_mgr))
{
case EFILEEXISTS:
break;
case EFILENOEXISTS:
break;
case EDIRNOTEMPTY:
break;
case EBADFILENAME:
break;
case EBADSEEKPOS:
break;
case EFILEEOF:
break;
case EFSFULL:
break;
case EFILEOPEN:
break;
case EBADPARM:
break;
}
return retval;

Actually a small proviso to that ...
after I write to a file I get a retval of 262 (in the code below).
switch (retval = IFILEMGR_GetLastError(_file_mgr))
{
case EFILEEXISTS:
break;
case EFILENOEXISTS:
break;
case EDIRNOTEMPTY:
break;
case EBADFILENAME:
break;
case EBADSEEKPOS:
break;
case EFILEEOF:
break;
case EFSFULL:
break;
case EFILEOPEN:
break;
case EBADPARM:
break;

return retval;

Actually a small proviso to that ...
after I write to a file I get a retval of 262 (in the code below).
switch (retval = IFILEMGR_GetLastError(_file_mgr))
{
case EFILEEXISTS:
break;
case EFILENOEXISTS:
break;
case EDIRNOTEMPTY:
break;
case EBADFILENAME:
break;
case EBADSEEKPOS:
break;
case EFILEEOF:
break;
case EFSFULL:
break;
case EFILEOPEN:
break;
case EBADPARM:
break;

return retval;

Problem solved.
As soon as I ran my app (from emulator) from another folder with only the runtime folders it worked fine .... god, what a waste of effort. lol
Does BREW not like too many files in a directory?????

Problem solved.
As soon as I ran my app (from emulator) from another folder with only the runtime folders it worked fine .... god, what a waste of effort. lol
Does BREW not like too many files in a directory?????

it can , the information is in the spec sheets.

it can , the information is in the spec sheets.

Spec sheets are in Japanese so I cannot read them. I am doing this app for KDDI in Japan.

Spec sheets are in Japanese so I cannot read them. I am doing this app for KDDI in Japan.

markeaston wrote:Spec sheets are in Japanese so I cannot read them. I am doing this app for KDDI in Japan.Just use docs from English SDK - works for me. Anyway, note that you have a maximum number of files and maximum space limitation both specified in your .mif file, as well as strange parameter of FS_LIMITS_PER_MODULE (which I'm not quite sure what is about) in emulated device configuration file (.qsc). However emulator does not emulate space limitation directly - instead it divides .dll size by 10 or something like that.

markeaston wrote:Spec sheets are in Japanese so I cannot read them. I am doing this app for KDDI in Japan.Just use docs from English SDK - works for me. Anyway, note that you have a maximum number of files and maximum space limitation both specified in your .mif file, as well as strange parameter of FS_LIMITS_PER_MODULE (which I'm not quite sure what is about) in emulated device configuration file (.qsc). However emulator does not emulate space limitation directly - instead it divides .dll size by 10 or something like that.