Include character to invalidate line (SD)

I’m finalizing a sketch that has as one of its functions delete / invalidate a SD line. I put “invalidate” because I think of including an initial index on the line which should be invalid so that later it does not copy it to another file. It happens that when my IF that will invalidate the line is true, I end up inserting $ at the “0” position of the following line, not the exact line I want. I could not solve this myself and would like some suggestions, please.

My SD file contains the following:

 ID.11111111 Hello ABCDEF
 ID.22222222 Hello ABCDEFGHI
 ID.33333333 Hello ABCDEFGHIJLM
 ID.44444444 Hello ABCD1234
(Something around 200 lines)

The data varies on each line, it starts with a null character just to allow the inclusion of an indicator.

So when my exclusion condition is true I call myFile.print ("&") to insert, the indicator is inserted into the subsequent line to that of the desired line.
For example, if I want to indicate the deletion of ID.22222222, my sketch inserts “&” in the line of ID.33333333, as below:

 ID.11111111 Hello ABCDEF
 ID.22222222 Hello ABCDEFGHI
&ID.33333333 Hello ABCDEFGHIJLM
 ID.44444444 Hello ABCD1234

My function:

void findUser (){  

        const byte                          numVectorUser              =  50;
        char                                vectorUser[numVectorUser]  =  {0};
        unsigned char                       index                      =   0;
        char                                cr;       
        char                                numberId[9]               =  {0};  
        unsigned long                       uuid;
        char *                              endptr;     
        byte                                tmp[4];
        unsigned char                       iterate                    =   0;
        unsigned char                       sum5;
        char *                              pegaVetorUser;
        myFile2 =, FILE_WRITE);;
            cr =;                                                     
            vectorUser[index] = cr;
              if(cr == '\n'){
                                for (iterate=0; iterate<8; iterate++){
                                      sum5 = iterate+5;  
                                      numberId[iterate] = vectorUser[sum5];
                                uuid = strtoul(numberId, &endptr, 16);
                                Serial.println(uuid, HEX);

                                for (int cnt = 0; cnt < 4; cnt++)
                                  tmp[3 - cnt] = numTag[cnt];                       

                                if (memcmp(tmp, (byte*)&uuid, 4) == 0)
                                      Serial.println(F("nothing done"));

I could not understand why, but I imagine someone with more experience might see what I do not see.

My thanks.

I could not understand why, but I imagine someone with more experience might see what I do not see.

There is a position in the file where the record to be "deleted" starts. There is a position where the record ends.

You find the end of the record, and, if it is to be "deleted", you write a '#' to the file after the end of the record to be deleted.

You need to keep track of where the record starts, and, when the record is to be deleted, seek() back to the start of the record, and write there.

Don't forget to keep track of where the end of the record is, so you can seek() back there after "deleting" the record, so you don't keep processing the same record over and over.

Using fixed length records would be so much easier...

Hi PaulS, thank you for your time.

I looked at the suggestion for your suggestion and tried, in a rough outline, to perform the insertion of a # into certain ones in the initial positions of my lines. I also looked at your suggestion of fixed-length records. I put 10 rows each with 53 characters, all 10 of the same size. I did seek (54) >> (54 is the beginning of line 2), and it went well, inserted right. But when I do seek (106), 3rd line, it starts to err and prints at 105, causing line 3 to come to 2, generating problem. Really, seeing for fixed records the idea is a lot easier, your comment is great. But I do not understand why if I do seek (106) or any other value it generates this error. My lines begin with 1 blank space and 52 characters.

My exclusions will be few. It will not be every day. Do you see how another applicable hypothesis would be to transfer the records to a temporary one, except the target line?
If yes, could you give an idea how to "skip" the line to be deleted, when there is the transfer from A.txt to B.txt? Thanks.

So, you wrote some code to diddle with some fixed length file. You didn't post the code or the file. Do you really think we can help? I'd need some crystal balls to do that. Mine are brass, though, so I can't help.

The usual way to delete a record from a file is to open two files. Until the end of the first file is reached, read a record. If you want the record, write it to the other. If you don't, don't write it.

When you get to the end of the first file, close them both. Then delete the first file, and rename the second one.

But, since the Arduino has limited memory, and having two open files needs more than half the memory it has, that may not be an option.

Alternatively, you could open the first file. Read the first record, counting characters. Close the file. If you want to keep the record, open the second file in append mode, and write the record. Open the first file, again, and seek to where you left off reading. Read the next record, incrementing the count of characters. Close the file. Write the record to the second file, of you want it. Repeat until all the records have been dealt with.

But, if you don't mind having one file, with valid and invalid records, keeping track of the spot where the valid/invalid marker goes, for each record, is possible.

I suspect that your problem with fixed length records is with how you open the file and how you write to it. If you are inserting characters in the file, as opposed to overwriting characters, you will have problems.