Having trouble with the SD library's File class

I have this code that is supposed to open/create and empty the specified file and then simply write 4 lines of text to the file.

But every time I examine the contents of the file on the SD card, it is empty.

So what is that you have to do with that File class to get it to actually commit what you have written to it to the physical SD card?

I don’t seem to have any problems with the read operations.

CTextFile is a wrapper class I have written to allow me to do text based write and reads etc and the source and header file are attached.

  if (SD.exists(m_strTXTEmailFilename))
  {
    CTextFile file(m_strTXTEmailFilename, FILE_WRITE);
    if (file)
    {
      file.writeLine(m_strEmail);
      file.writeLine(m_strMailServer);
      file.writeLine(m_strUsername);
      file.writeLine(m_strPassword);
    }
    else
      error(F("Wifi.cpp"), __LINE__);
    file.close();
  }

TextFile.cpp (2.29 KB)

TextFile.h (1.62 KB)

You could have posted those files, rather than attaching them. They're not very big. You left out the "common.h" file, too, so no one can actually test or modify the code to get it working.

A full compileable *.ino file would help, too.

CTextFile is a wrapper class I have written

Pretending to be a Microsoft developer? Why? Isn’t the word “class” in the file sufficient to define that TextFile is a class?

But every time I examine the contents of the file on the SD card, it is empty.

Is that the case WITHOUT using the wrapper class? In other words, are we debugging a hardware problem (with the SD shield), a software problem (with the SD and related classes), or a development problem (with your wrapper class)?

PaulS: Pretending to be a Microsoft developer? Why? Isn't the word "class" in the file sufficient to define that TextFile is a class?

You may not like the Microsoft naming convention but I have not come across a better one. The C clearly denotes that identifier as a class, not a struct or anything else. When I first learned C at Latrobe University I also used the 'TextFile' type naming convention and, at times, I go confused between class definitions and variable names etc.

I also use the microsoft m_n.../n..., m_str.../str... naming conventions. Sometimes I invent my own along similar lines, e.g. m_array.../array...

It just avoids so much confusion when you return to your code months or years later.

PaulS: Is that the case WITHOUT using the wrapper class? In other words, are we debugging a hardware problem (with the SD shield), a software problem (with the SD and related classes), or a development problem (with your wrapper class)?

My wrapper class functions just call functions on the TextFile object inside so I can't see how that can be a problem.

Like I said I can edit the contents in windows and then read them just fine on the arduino.

It has got to be something to do with the way I am opening the file.

The examples show you how to read a file, append to a file and create a file.

But there are none that show you how to rewrite a file - open it for writing and empty the contents, i.e. no examples that use the o_trunc attribute.

I am wondering if that is the cause of this strange error.

Come to think of it I originally was opening files for writing using O_WRITE | O_CREATE, and assumed that it was equivalent to that in Unix and Borland C where it would open the file for writing and empty the contents.

But instead I found that that O_WRITE | O_CREATE was the same as readwrite in the other to platforms, and I was appending new data to the end of the existing contents.

Write operations were working fine then.

Perhaps I need to ditch this mode and have my wrapper class delete the file and then re-create it.

Then I can just append to the end of an empty file.

boylesg: The examples show you how to read a file, append to a file and create a file.

What examples?

OldSteve: What examples?

The examples that came with the SD library?

Never mind anyway I just figured out what I was doing wrong.

My ::dump() function was not closing the file after it dumped the contents.

Subsequent calls to open must have then been destroying the file contents.

And I think this is a far less misleading means of opening files in different modes:

define READ O_READ

define READ_APPEND (O_READ | O_WRITE | O_CREAT)

define APPEND (O_WRITE | O_CREAT)

define REWRITE (O_WRITE | O_CREAT | O_TRUNC)

The author had (O_READ | O_WRITE | O_CREAT) defined as FILE_WRITE

boylesg: The examples that came with the SD library?

Ah, now I'm with you. I thought you meant examples of your class. It's late at night here, (1am now), and I get slower as the day wears on. :D (And I looked 3 times to see if you'd attached some examples that I'd missed. :-* )

A moot point now, anyway. Glad you got it sorted out.

My ::dump() function was not closing the file after it dumped the contents.

That is exactly why I asked if we were debugging the SD library or your library. Turns out we were debugging your library.