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

Developer

Forums

Forums:

Hello,

I am writing an application that tries to create a file:

/*
* Test the file before opening. BREW doesn't want to see the
* _OFM_CREATE flag if the file already exists, and it doesn't
* want to see any other flag if the file doesn't exist.
*/
f_exists = IFILEMGR_Test(pIFileMgr, name) == SUCCESS ? 1 : 0;
if (f_exists)
{
DBGPRINTF("file exists");
LF_CLR(_OFM_CREATE); /* Clear _OFM_CREATE. */
}
else
{
DBGPRINTF("file does not exists - creating..");
LF_CLR(~_OFM_CREATE); /* Leave only _OFM_CREATE. */
}

ret = 0;

/* I added this comment line and it works now... I don't know why -.-;;; */
// DBGPRINTF("open file flag: %x", flags);

if ((pIFile =
IFILEMGR_OpenFile(pIFileMgr, name, (OpenFileMode)flags)) == NULL) {

DBGPRINTF(">>>>>>>>>>>>> something went wrong with file opening");

switch(IFILEMGR_GetLastError(pIFileMgr))
{

case EFILEEXISTS : DBGPRINTF("File exists");

break;
case EFILENOEXISTS : DBGPRINTF("File does not exist");

break;
case EDIRNOTEMPTY : DBGPRINTF("Directory not empty");

break;
case EBADFILENAME : DBGPRINTF("Bad file name");

break;
case EBADSEEKPOS : DBGPRINTF("Bad seek position");

break;
case EFILEEOF : DBGPRINTF("End of file");

break;
case EFSFULL : DBGPRINTF("File system full");

break;
case EFILEOPEN : DBGPRINTF("File already open");

break;
case EBADPARM : DBGPRINTF("Invalid parameter");
break;
}

The problem is that after the app checks there is no file, it tries to open up the file with _OFM_CREATE flag. The debug shows the flag is set correctly (0x0004, as defined), but IFILEMGR_OpenFile throws NULL and get last error has 'file does not exist' (ofcourse! the file does not exist, that's why I'm trying to create!).

This problem is very strange, because when I insert a DBGPRINTF("flag: %x", flag) that prints out the flag, the application runs fine! (it's also strange that when I put a DBGPRINTF that just prints out a message such as DBGPRINTF("hello, world"); the application doesn't run.

I wasn't able to run this code on the real device, since I'm testing around using BREW simulator.

I've created similar logics with my other applications (where it checks the file by using IFILEGMR_Test and then moves on to create the file), but hadn't met any problems.

Does anybody has any explanation to this??

Please help me..!

In addition,
In many parts of the code, the brew application simply wouldn't work properly on the simulator without the help of the mighty DBGPRINTF () function. Injecting the DBGPRINTF in certain parts of the code somehow miraculously solves many unexplanable problems.
Does this also occurs on real H/Ws?????

In addition,
In many parts of the code, the brew application simply wouldn't work properly on the simulator without the help of the mighty DBGPRINTF () function. Injecting the DBGPRINTF in certain parts of the code somehow miraculously solves many unexplanable problems.
Does this also occurs on real H/Ws?????

I think the problem is caused by the visual studio 6 that I'm using with BREW SDK. One of my colleagues has commented that compiling the codes using Visual studio 2005 express edition did not cause such problems. So, if anybody has met similar problem, please change your compiler and try again... I've been barking at the wrong tree!

I think the problem is caused by the visual studio 6 that I'm using with BREW SDK. One of my colleagues has commented that compiling the codes using Visual studio 2005 express edition did not cause such problems. So, if anybody has met similar problem, please change your compiler and try again... I've been barking at the wrong tree!

I've never heard of anything like this. You will have a problem if you name a file with any uppercase letters. For instance, if the file name is "Foo.bar", the BREW path "Foo.bar" will not work. However, "fs:Foo.bar" should work. It doesn't sound like this is your problem, but this seems to be the most common issue people run into with opening files.

I've never heard of anything like this. You will have a problem if you name a file with any uppercase letters. For instance, if the file name is "Foo.bar", the BREW path "Foo.bar" will not work. However, "fs:Foo.bar" should work. It doesn't sound like this is your problem, but this seems to be the most common issue people run into with opening files.

Hi guys:
I, too, have this problem with the 3.1.5 simulator :confused:
Same code works with no problem with the 2.X simulator.
The code works perfectly on our 3.x phones.
I'm compiling with Microsoft Visual C++ 2005.
I verified that I was compiling against the 3.1.5 includes.
Pity the 3.1.5 emulator has so many problems :(

Hi guys:
I, too, have this problem with the 3.1.5 simulator :confused:
Same code works with no problem with the 2.X simulator.
The code works perfectly on our 3.x phones.
I'm compiling with Microsoft Visual C++ 2005.
I verified that I was compiling against the 3.1.5 includes.
Pity the 3.1.5 emulator has so many problems :(

baitisj wrote:Hi guys: I, too, have this problem with the 3.1.5 simulator :confused: Same code works with no problem with the 2.X simulator. The code works perfectly on our 3.x phones. I'm compiling with Microsoft Visual C++ 2005. I verified that I was compiling against the 3.1.5 includes. Pity the 3.1.5 emulator has so many problems :( And do you have any uppercase letters in your file names?

baitisj wrote:Hi guys: I, too, have this problem with the 3.1.5 simulator :confused: Same code works with no problem with the 2.X simulator. The code works perfectly on our 3.x phones. I'm compiling with Microsoft Visual C++ 2005. I verified that I was compiling against the 3.1.5 includes. Pity the 3.1.5 emulator has so many problems :( And do you have any uppercase letters in your file names?

have you checked the previliges of your applet?

have you checked the previliges of your applet?

For me if this problem Happen. i generate the mif file again from scrach and it will start working :D

For me if this problem Happen. i generate the mif file again from scrach and it will start working :D

markb wrote:And do you have any uppercase letters in your file names?
I'm using no uppercase letters. The file that I'm attempting to create is called "testfile." Yes, filesystem privileges have been assigned to the application, and I tested this with and without system-level privileges.

markb wrote:And do you have any uppercase letters in your file names?
I'm using no uppercase letters. The file that I'm attempting to create is called "testfile." Yes, filesystem privileges have been assigned to the application, and I tested this with and without system-level privileges.

baitisj wrote:I'm using no uppercase letters. The file that I'm attempting to create is called "testfile." Yes, filesystem privileges have been assigned to the application, and I tested this with and without system-level privileges.
The case shouldn't matter when you're creating a file, anyway. (Unless the file already exists, perhaps.) Privileges shouldn't matter, either, once you've obtained the IFileMgr.
I suppose you might be able to create a MIF with an ACL that denies the app access to its own home directory, which could account for the solution of regenerating the MIF. If that's possible, it's probably not that likely.
Are you also getting EFILENOEXISTS, or something else?

baitisj wrote:I'm using no uppercase letters. The file that I'm attempting to create is called "testfile." Yes, filesystem privileges have been assigned to the application, and I tested this with and without system-level privileges.
The case shouldn't matter when you're creating a file, anyway. (Unless the file already exists, perhaps.) Privileges shouldn't matter, either, once you've obtained the IFileMgr.
I suppose you might be able to create a MIF with an ACL that denies the app access to its own home directory, which could account for the solution of regenerating the MIF. If that's possible, it's probably not that likely.
Are you also getting EFILENOEXISTS, or something else?

I've had the same problem since Simulator version 3.1.2.
IFILEMGR_OpenFile always returns EFSFULL when I specify _OFM_CREATE. :mad:
This happens with any device skin I choose.
Sure wish someone from Qualcomm would chime in on this!

I've had the same problem since Simulator version 3.1.2.
IFILEMGR_OpenFile always returns EFSFULL when I specify _OFM_CREATE. :mad:
This happens with any device skin I choose.
Sure wish someone from Qualcomm would chime in on this!

Did you tried the method in my above post. [Regenerating the mif file]

Did you tried the method in my above post. [Regenerating the mif file]

I'm using BREW MIF Editor 3.0.4.7 and still having the same problem. :confused:

I'm using BREW MIF Editor 3.0.4.7 and still having the same problem. :confused:

Particleman wrote:I've had the same problem since Simulator version 3.1.2.
IFILEMGR_OpenFile always returns EFSFULL when I specify _OFM_CREATE. :mad:
This happens with any device skin I choose.
Sure wish someone from Qualcomm would chime in on this!
You're seeing a different problem. EFSFULL likely means you are exceding the file system limit specified by the skin. Note that all the files in you app directoy count against this limit (.c, .lib, .obj, ...) unless you except those extensions in the simulator config file.

Particleman wrote:I've had the same problem since Simulator version 3.1.2.
IFILEMGR_OpenFile always returns EFSFULL when I specify _OFM_CREATE. :mad:
This happens with any device skin I choose.
Sure wish someone from Qualcomm would chime in on this!
You're seeing a different problem. EFSFULL likely means you are exceding the file system limit specified by the skin. Note that all the files in you app directoy count against this limit (.c, .lib, .obj, ...) unless you except those extensions in the simulator config file.

Good idea, but I previously tried that:
Max Files Allowed To Create: 65535
Max Space (bytes) Allowed To Write: 4294967295
The directory the simulator points to contains less than 65000 files and the hard drive has plenty of free space.

Good idea, but I previously tried that:
Max Files Allowed To Create: 65535
Max Space (bytes) Allowed To Write: 4294967295
The directory the simulator points to contains less than 65000 files and the hard drive has plenty of free space.

It could be that those values are too big, and some variable somewhere is overflowing. I think the file number limit is the only one that comes into play on file open, so try setting that to something smaller.

It could be that those values are too big, and some variable somewhere is overflowing. I think the file number limit is the only one that comes into play on file open, so try setting that to something smaller.

I just tried 32767 and 30000 and still have the same error.
I did have success when I moved most of the other files and directories out of the Applet Directory. There are ~20,000 files and ~300 directories there.
This is most unfortunate, however, since my preference is to organize in this manner:
Applet Directory:
-- project directory 1
-- project directory 2
-- project directory 3
-- ...
I then specify the MIF file directory as any one of the above project directories for whichever project I'm working on. I like this organization and it matches our source control as well.
Is there a better way to organize multiple projects and not have EFSFull errors?
Thanks

I just tried 32767 and 30000 and still have the same error.
I did have success when I moved most of the other files and directories out of the Applet Directory. There are ~20,000 files and ~300 directories there.
This is most unfortunate, however, since my preference is to organize in this manner:
Applet Directory:
-- project directory 1
-- project directory 2
-- project directory 3
-- ...
I then specify the MIF file directory as any one of the above project directories for whichever project I'm working on. I like this organization and it matches our source control as well.
Is there a better way to organize multiple projects and not have EFSFull errors?
Thanks

I guess there must be some sort of inherent limit that you can't override. You can exclude certain file extensions by editing BREW_Emu.dat. (Look for the [FileSystem] section.) You might be able to work around this limitation that way.
I like to keep my project directories totally separate from my app directory. I have an "install" target in my makefiles that copies the appropriate files to the applet directory.

I guess there must be some sort of inherent limit that you can't override. You can exclude certain file extensions by editing BREW_Emu.dat. (Look for the [FileSystem] section.) You might be able to work around this limitation that way.
I like to keep my project directories totally separate from my app directory. I have an "install" target in my makefiles that copies the appropriate files to the applet directory.

At your suggestion, I added 'cpp' to the list of extensions and it now works!
Strange that the simulator is having trouble counting files. Strange also that there is not a way to simply enter -1 (or something) so that the simulator does not make this check.
Anyway, you rock! Thanks for the help.

At your suggestion, I added 'cpp' to the list of extensions and it now works!
Strange that the simulator is having trouble counting files. Strange also that there is not a way to simply enter -1 (or something) so that the simulator does not make this check.
Anyway, you rock! Thanks for the help.

Check this thread
http://brewforums.qualcomm.com/showthread.php?p=58391
I hope this solves ur problem

Check this thread
http://brewforums.qualcomm.com/showthread.php?p=58391
I hope this solves ur problem

skumar_rao wrote:For me if this problem Happen. i generate the mif file again from scrach and it will start working :D
After many hours of trying to figure out this same problem, Skumar's suggestion fixed it for me. Thanks Skumar, this was a painful one.
-Casten
Addendum - 10-05-07
I have encountered a similar problem since posting this. This time it was due to my app name being too long. I shortened the appname, updated the app directory and mif names to match and once again I could open files. This was also a pain to track down.
-Casten

skumar_rao wrote:For me if this problem Happen. i generate the mif file again from scrach and it will start working :D
After many hours of trying to figure out this same problem, Skumar's suggestion fixed it for me. Thanks Skumar, this was a painful one.
-Casten
Addendum - 10-05-07
I have encountered a similar problem since posting this. This time it was due to my app name being too long. I shortened the appname, updated the app directory and mif names to match and once again I could open files. This was also a pain to track down.
-Casten

Ifile_getlasterror(.....) Api Returns Efsfull If There Is No Space In File System Or Module Exceeds Its Limit.how To Implement Same Thing For Iringermgr_create(....) Api. I.e. If File System Is Full Iringermgr_create(....) Api Should Return Efsfull.

Ifile_getlasterror(.....) Api Returns Efsfull If There Is No Space In File System Or Module Exceeds Its Limit.how To Implement Same Thing For Iringermgr_create(....) Api. I.e. If File System Is Full Iringermgr_create(....) Api Should Return Efsfull.

IRingerMgr_Create internally calls IFILEMGR_GetLastError whenever file operation fails, so it should take care of that.

IRingerMgr_Create internally calls IFILEMGR_GetLastError whenever file operation fails, so it should take care of that.

Quote:I, too, have this problem with the 3.1.5 simulator
Same code works with no problem with the 2.X simulator.
we were also facing this issue, but once we changed our workspace from "Abcd" to "abcd" i.e all in small case, all goes well.

Quote:I, too, have this problem with the 3.1.5 simulator
Same code works with no problem with the 2.X simulator.
we were also facing this issue, but once we changed our workspace from "Abcd" to "abcd" i.e all in small case, all goes well.

This is only for Brew 3.x

This is only for Brew 3.x