0
votes

I am porting existing C++ app (game engine) to support Windows Store 8 and Windows Phone 8.1 Apps and I am having problem with the _wfindfirst function. On regular Win32 it returns a handle to the first found element matching the pattern. we use it mainly to get information about directory or file.

The function I am trying to get working on WindowsPhone/Windows Store App is like this:

bool sys_GetFileInfo(const std::string& path, FileInfo* info) {
  ...
  long handle = _wfindfirst(p.c_str(), &item); // path gets converted to wstring
  if (handle != -1L) {
    info->size = (item.attrib & _A_SUBDIR) ? -1 : item.size;
    info->modifiedAt = item.time_write;
    _findclose(handle);
    return true;
  }
  ...
}

So it was used to retrieve file size and modification date (and if it happened to be directory the size was set to -1)

The first usage was to get info about working directory of an exe so in case of the WinRT/WP/WS I am using it with the path provided by

std::wstring wpath = Windows::ApplicationModel::Package::Current->InstalledLocation->Path->Data();

The path in this case is:

 wpath = L"C:\\foo\\winrt\\winrt\\Debug\\foo_winrt.Windows\\AppX"

The problem is that it always returns -1, when I check the error string with GetLastError() code I get the access denied error. This is confusing as in my understanding application should have read access to this location so _wfindfirst is a read operation right? On Win32 it worked given a regular directory path.

Why this function fails? Is there any other viable option to achieve the same result for WinRT ?

1

1 Answers

0
votes

If still relevant, it seems you are not able to use standard C++ functions to access file system outside your app's sandbox (installed location and local app folder). They will fail with Access denied error. I think they behave pretty much the way CreateFile2 behaves, and according to MSDN:

When called from a Windows Store app, CreateFile2 is simplified. You can open only files or directories inside the ApplicationData.LocalFolder or Package.InstalledLocation directories.

In your case, as I can see, the installed location points to a development folder, and I think the system decides that this location isn't inside your app's sandbox.

Consider using Windows Runtime APIs from Windows.Storage namespace. These APIs can be used to access any file in the file system.