From MS page Byte order mark Description EF BB BF UTF-8 FF FE UTF-16, little endian FE FF UTF-16, big endian FF FE 00 00 UTF-32, little endian 00 00 FE FF UTF-32, big-endian Note: Microsoft uses UTF-16, little endian byte order.

This is what I used in a project few days ago: std::basic_string<TCHAR> sFileContent = _T(""); if (sizeof(TCHAR) > 1) // if wide char sFileContent += 0xFEFF; // this header tells notepad to read file as Unicode sFileContent += _T("My favorite Dave Attell quote: "); sFileContent += _T("Yeah, I know, some people are against drunk driving, "); sFileContent += _T("and I call those people 'the cops'. But you know, "); sFileContent += _T("sometimes, you've just got no choice; those kids gotta get to school!"); // save to file routine

If you are using std::wstring's, you need std::wcout. std::cout works *only* with std::strings. Since there is no _tcout, I like to use _tprintf (and _T macro) when printing Unicode stuff in console. Take this code for example: std::wstring test1 = _T("test1"); std::cout << test1.c_str() << endl; // prints junk "0012DE10" std::wcout << test1.c_str() << endl; // prints "test1" But to do it "properly", something like this is needed: std::basic_string<TCHAR> test1 = _T("test1"); _tprintf(_T("Testing string is: %s"), test1.c_str()); I hope that helps. Best regards, loreia

modified on Saturday, January 17, 2009 12:55 PM

This was my C++ primer: "Teach Yourself C++ in 21 Days" [^], Jesse's explanations of classes and inheritance are great for beginners. Book teaches you C++ in logical and organized manner, and is perfect for beginners.

Hi David, thanks for your suggestion. GetFileAttributesEx() won't help me. I had problems understanding why ::FindFirstFile and GetFileAttributes() report different set of file attributes on FAT32. And now I get it, TEMP files are not flushed to HDD, and therefore limitations of FAT can be see with ::FindFirstFile and not with GetFileAttributes(). I made a small test in which I created a file on USB stick (with FAT32 file system), then added a TEMP attribute to it and: a) read file attributes right after creating file b) then I safely removed USB drive (forcing windows to flush file to FAT) c) re-read file attributes, now both ::FindFirstFile and GetFileAttributes() reported correct values Now I can safely continue developing my enumeration class. One more time, a BIG thank you to all three of you for your help, suggestions and explanations. Best regards loreia

What a great explanation, Now I fully understand what happened in my program. Thanks a lot, I owe you one :) Best regards, loreia

David, thank you a lot for your answer. I know from experience that FAT32 doesn't support encryption, so answer to your question is: no. LOL So, TEMP attribute is NTFS specific, and it is not supported on FAT32. Thanks for clarifying that, but what I don't understand is why SetFileAttributes returns TRUE when setting TEMP attribute to a file on FAT32. It SetFileAttributes function returned FALSE I wouldn't be in this mess in the first place. My understanding is: if FAT32 doesn't support TEMP files, than SetFileAttributes should fail to set TEMP attribute. I was wrong in presuming that "error" (for the lack of better description) was in FindFirstFile. But in fact FindFirstFile correctly reports that TEMP attribute is not set on FAT32 (as it cannot be set on FAT32). And the real problem is in SetFileAttributes/GetFileAttributes functions that *claim* that file has a TEMP attribute set even on FAT32 (and this is in direct contradiction to FAT32 File System Specification that you posted a link for). I you know why are SetFileAttributes/GetFileAttributes acting in this way, your explanation would help me a lot. Best regards loreia

This post brought smile to my face, I too am an electronics engineer and I program microcontrollers in my spare time (Microchip's PIC family) and my next project (if I ever find time to do it, that is) is to implement procedure to save data (collected from various sensors) on USB stick. Back to topic... I think Windows simply flushes data on USB stick because they are removable, and that is the only reason I can see the file with TEMP attribute. So it is probably not specific to my UBS stick. But I was thinking along the same lines, so I tested on three different USB stick and two computers, and then I created a small FAT32 (and FAT) partition on my hard drive and tested it there too. I got the same results everywhere, FindFirstFile identifies TEMP file only on NTFS partitions :(

Thanks, you last suggestion helped me better understand how TEMP files work. When I run test program on my hard drive, "test_file.txt" is not created at all, Explorer simply doesn't show it. I can see file only when I run program on my USB drive. After realizing that, I re-read this sentence from MSDN: "Specifying the FILE_ATTRIBUTE_TEMPORARY attribute causes file systems to avoid writing data back to mass storage if sufficient cache memory is available, because an application deletes a temporary file after a handle is closed. In that case, the system can entirely avoid writing the data." So, TEMP file is held in memory as long enough cache memory is available. And after seeing that file is NOT deleted on my USB stick, I can verify that application is the one responsible for deleting file (unless FILE_FLAG_DELETE_ON_CLOSE is set in CreateFile) Now, at least I fully understand what MSDN documentation says about FILE_ATTRIBUTE_TEMPORARY :) . Off course, my problem still remains. GetFileAttributes and FindFirstFile *should* see the same set of file attributes, and should report the same DWORD value. And BTW, you really have a "hawk eye", I meant to call CreateFile with FILE_ATTRIBUTE_TEMPORARY parameter but I made a mistake when copied source code here (in original that parameter is "*iter"). But it doesn't change much, no matter how I create file, once I set TEMP attribute, FindFirstFile chokes on it(on FAT32).

Thanks again :-D I've read that sentence like 300 times in last few days, and I must admit that I don't fully understand it. OK, English is my second language (third in fact) and I may be missing something, but this is how I see it: When application sets FILE_ATTRIBUTE_TEMPORARY attribute this information *should* be written somewhere in file system, and GetFileAttributes and FindFirstFile *should* read the same thing from file system. I don't understand why these two functions report different Attributes on FAT. Now, I can implement my class in such a way that when searching for FILE_ATTRIBUTE_TEMPORARY attribute, my class would additionally call GetFileAttributes within FindNextFile block. But I find this workaround a bit clumsy, and I was hoping to avoid it. Best regards loreia

Diversity is a good thing :) .net is good, but it is far from perfect. It might be easier to learn than MFC, but that doesn't mean that thousands of MFC programmers are going to switch to .net. They already *know* MFC, there is not much need for them to switch to anything else. I've used both, and I still prefer C++/MFC than C#/.net for simple projects. But C#/.net is my choice when I work with databases. As I said it is about diversity, everyone pick what he/she likes.

Thank you for your answer, I guess I was to hasty to post my question (and the fact that I went to bed at 4:30 AM last night certainly didn't help). I forgot to say that I removed all error checking and file handles because it did not affect my problem, and I wanted a simplest/shortest possible test. The same thing happens even if file handle is closed (I even tried calling ::Sleep(5000) right after CloseHandle, just to be sure (I was also desperate :-)). Basically, my Unit test goes through a loop of all possible file attributes, it creates a new file, sets one Attribute and checks if my enumeration class finds the file. If it does, test is successful, and loops goes to test another Attribute. And all is fine until FILE_ATTRIBUTE_TEMPORARY is tested, and only if I start tests on my USB drive (which is FAT32 based), on my hard drive test works fine. You had a very good idea, but unfortunately that is not it :-( Best regards, loreia

I am writing a small article about file enumeration, and in one of my CppUnit test I *discovered* that FindFirstFile/FindNextFile won't correctly report file attributes on FAT32 and FAT16. Specifically, FILE_ATTRIBUTE_TEMPORARY attribute is the problem here: Here is what my code does:

// first I set desired attribute
SetFileAttributes(sTestFile.c_str(), FILE_ATTRIBUTE_TEMPORARY);

// then I read attributes with GetFileAttributes
DWORD attr_1 = GetFileAttributes(sTestFile.c_str());
// attr_1 is FILE_ATTRIBUTE_TEMPORARY on all three FS tested (NTFS, FAT32 and FAT16)

// then I read attributes with FindFirstFile
FindFirstFile(sTestFile.c_str(), &fd);

// now I get that fd.dwFileAttributes equals FILE_ATTRIBUTE_NORMAL on FAT32 and FAT16, but FILE_ATTRIBUTE_TEMPORARY on NTFS !!!!

It took me nearly a day to realize that problem is due to File system and not my code. And now after spending hours going through on-line documentation I decided to ask here: 1. Is this documented behavior or a bug? 2. Am I doing something wrong in my code. Maybe it is something about temporary files that I failed to take into account. Any help would be highly appreciated. I have tested this on two computers, both running XP, and I get same results on both. Finally, here is a simple console project that demonstrates the problem:

#include "tchar.h"
#include "Windows.h"
#include
#include

using namespace std;

int _tmain(int argc, _TCHAR* argv[])
{
basic_string sPath = _T("");
basic_string sTestFile = _T("\\test_file.txt");
TCHAR root[256] = {0};
DWORD size = 256;
WIN32_FIND_DATA fd;

if (::GetCurrentDirectory(size, root) != 0)
    sPath = root;
else return 1;

sPath += sTestFile;

CreateFile(
			sPath.c\_str(), 
			GENERIC\_READ | GENERIC\_WRITE, 
			FILE\_SHARE\_READ, 
			NULL, 
			CREATE\_ALWAYS, 
			FILE\_ATTRIBUTE\_TEMPORARY, 
			NULL);	// creates file with two attributes set: FILE\_ATTRIBUTE\_ARCHIVE and FILE\_ATTRIBUTE\_TEMPORARY

\_tprintf(\_T("\\nA file %s is created...\\n"), sPath.c\_str());
\_tprintf(\_T("\\nFile attributes (as reported by GetFileAttributes() ) are now: %x \\n"), GetFileAttributes(sPath.c\_str()));

\_tprintf(\_T("\\nExplicitly set FILE\_ATTRIBUTE\_TEMPORARY attribute...\\n"));
SetFileAttributes(sPath.c\_str(), FILE\_ATTRIBUTE\_TEMPORARY);
// this line ALWAYS prints: 100 (code for FILE\_ATTRIBUTE\_TEMPORARY)
\_tprintf(\_T("\\nFile attr