Announcement

Collapse
No announcement yet.

file_Exists bug

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • meldavia
    replied


    There are no known issues, a code example showing up your problem would really help.

    Leave a comment:


  • atemybuick
    replied


    This file_Exists() bug and the general problem with file services that use text indirectly is still a problem!? I'm running the latest firmware on a uOLED-32028 and still can't use a variable for the filename.

    Leave a comment:


  • meldavia
    replied
    Hi, you can have many files open if you wish, however each time you open a file, you consume (a precious!) 540 bytes for a file control block and sector buffer which must be released. The order of release should be the same as the order of creation, else holes may be left in memory (there is no garbage collection). file_Unmount releases another small amount of memory, but has no means of keeping track of what is open due to the limited amount of memory that we have, and more importantly, it locks the low level card access so a crash or errant program will find it more difficult to damage the file system. During development, I usually sprinkle something like:-

    print("Memory available = ",mem_Heap(),"\n");

    at certain points in the program (and especially at the end).

    Leave a comment:


  • mvandere
    replied


    A file open (create) giving a return code of 17.
    Got a handle (so to speak) on this one.

    Return code 17, is, of course, "Malloc could not allocate the FILE struct"

    I am getting it when I open a lot of files and fail to close them. Whilst I would expect this to fail, eventually, I was thinking that the file_Unmount that is done after every create would free up all the memory allocated since the file_Mount, but this is obviously not the case.

    This may not be a bug, and it is quite possible it can't be fixed due to 'design restrictions'.

    Hey, I can still get more files open than in MSDOS 3.x
    Attached files CrtFileNoClose.4dg (1.2 KB)

    Leave a comment:


  • mvandere
    replied


    An interim release 1.05a is coming very soon that addresses most known bugs at this time.
    Does that include, dare I ask it...

    A file open (create) giving a return code of 17. After opening and closing a lot (> 50) of files, 'hard on' once it starts.

    Excessive write times to an SD card file. I've seen consistent repeatable (as in across many runs) response times to a single file_PutC of 250ms and even 23.6 seconds (one putc out of many thousands). The problem goes away after reformatting the card and I can't get to recreate the situation reliably and consistently. Windows checkdisk reports no errors on the card.

    Leave a comment:


  • meldavia
    replied


    Sorry you have been scratching your heads over this, there is a bug in PmmC's v1.05 in the string handling area. All file services that use text indirectly as an argument exhibit the same problem. An interim release 1.05a is coming very soon that addresses most known bugs at this time.

    Leave a comment:


  • steve4690
    replied


    I've done a bit of digging and can get the functions discussed working. I think there's a bug in file_Erase().

    file_Dir(), file_Open(), and file_Exists() all expect a byte pointer pointing to the file name.
    I.e.
    var fname[n];
    var bpfname;
    bpstr := str_Ptr(str);
    ...pass bpfname as the file name

    file_Erase() looks like it requires a word pointer pointing to the file name. I.e.
    var fname[n];

    ...pass &fname
    as the file name (or bpfname>>1)

    The attached code demonstrates the above.

    Regs
    Steve

    Attached files filetest.4dg (4.5 KB)

    Leave a comment:


  • mvandere
    replied


    So, it appears that most file functions don't work reliably when passed a filename of the type:-

    var filename1[12] ;

    They do appear to work reliably when passed filenames of the type:-

    var filename2 ;

    But in all the examples I have seen, and all the ways I have tried, I cannot seem to get a dyamically created filename into filename2, whereas there are plenty of examples as to how to get a dynamically created filename into filename1.

    So, how do I convert type of filename1 to type of filename2?

    I have tried & and str_ptr, but these do not appear to give the desired result, what am I missing?

    Leave a comment:


  • mvandere
    replied


    I'm surprised no one has told me off yet

    There isn't a bug in file_Exists, it's the way I've built the string for the variable filename.

    I don't fully understand why yet, Just thought I'd let you know soonest

    Leave a comment:


  • mvandere
    started a topic file_Exists bug

    file_Exists bug

    When using file_Exists and the filename is a variable and the file existed and has been deleted file_Exists reports the file as existing. This makes the circumvention for the file_Erase bug useless when using variables for filenames.

    Output of test program (when using a newly formatted SD card)

    Dir output:-
    A does NOT exist as a constant filename
    A does NOT exist as a variable filename
    B does NOT exist as a constant filename
    B does NOT exist as a variable filename
    Creating file A
    Creating file B
    Erasing A
    Dir output:-
    B.
    A does NOT exist as a constant filename
    A exists as a variable filename
    B exists as a constant filename
    B exists as a variable filename
    Test program attached


    Attached files FileExisErr.4dg (2.1 KB)
Working...
X