0
#include <iostream>
#include <fstream>
#include <string>
using namespace std;

int main(int argc, char **argv) {

    try
    {
        ifstream file;
        string simplePath = "I:/foo.conf";
        string markPath = "I:/Folder_à/foo.conf";

        file.exceptions(ifstream::failbit | ifstream::badbit | ifstream::eofbit);     

        file.open(simplePath.c_str());  // ok
        file.open(markPath.c_str());    // exception ios_base::failbit set
    }

    catch (ifstream::failure f)
    {
        cout << "Exception " << f.what() << endl;
        return 1;
    }

    return 0;
}

If a file has an accent mark (e.g. à) within its pathname, the open() function throwns a ios_base::failbit set exception.

A simple fix is 

file.exceptions(ifstream::badbit | ifstream::eofbit); // removed failbit from the mask

but is not what I want: if possible I'd like to set the failbit as normal.

I'm using Visual Studio 2012 and Windows 8.

svick
  • 236,525
  • 50
  • 385
  • 514
eang
  • 1,615
  • 7
  • 21
  • 41
  • 1
    Are you sure you can use those with narrow strings? – chris Jan 23 '13 at 16:04
  • 1
    what is the source file encoding ? it is highly possible that it does not match Windows' encoding used for the file system. – SirDarius Jan 23 '13 at 16:05
  • 2
    @chris is allowed in posix/linux. UTF-8 – nishantjr Jan 23 '13 at 16:05
  • @njr, Yeah, but it's Windows 8 :p – chris Jan 23 '13 at 16:06
  • `wchar_t path[] = L"I:/Folder_à/foo.conf"; std::fstream file(path);` You can use that on MSVC. Note that it is a non-standard MSVC specific api. – Alok Save Jan 23 '13 at 16:07
  • @chris I dont'know, but in Linux this code compiles fine. – eang Jan 23 '13 at 16:16
  • @SirDarius The source file encoding is UTF-8 - 65001 – eang Jan 23 '13 at 16:16
  • @AlokSave I can't use wchars, this will be a cross-platform code. – eang Jan 23 '13 at 16:17
  • 3
    Then this explains it because according to this answer: http://stackoverflow.com/a/2051018/393701 Windows filenames (on NTFS) are stored as UTF-16, hence the necessary use of wchar_t, because the ANSI versions of Windows functions do not understand UTF-8. – SirDarius Jan 23 '13 at 16:19
  • So I'm forced with wchars? A basic operation (such file opening) really needs a platform-specific code? – eang Jan 23 '13 at 16:28
  • That would indeed suck, because that pathname just contains high-asci, and I don't see anything wrong with it. If it means anything at all (and I don't see how it could), it works on my OS X (10.8), so once gain, it sucks to be Windows of this goes where it seems to be heading. Offhand, what does the *file* encoding have to do with *openning* it? The file *system* should matter on that regard; not whats *in* the file itself (or did I miss something obvious (happens a lot))? – WhozCraig Jan 23 '13 at 16:59

0 Answers0