Announcement

Collapse
No announcement yet.

file_Exists bug

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

  • 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)

  • #2


    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

    Comment


    • #3


      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?

      Comment


      • #4


        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)

        Comment


        • #5


          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.
          Regards,
          Dave

          Comment


          • #6


            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.

            Comment


            • #7


              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)

              Comment


              • #8
                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).
                Regards,
                Dave

                Comment


                • #9


                  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.

                  Comment


                  • #10


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

                    Comment

                    Working...
                    X