locked
In Store APP FindFirstFileEx is not working

    Question

  • Hi,

    I am trying to port win32 dll code for ARM(surface). I try to use 'FindFirstFileEx' its not working.

    fileFindData = new WIN32_FIND_DATA;
    hFind = FindFirstFileEx(findName.n_str(),FindExInfoStandard,(WIN32_FIND_DATA*)fileFindData,FindExSearchNameMatch,NULL,0);
    Is there any alternative, can we do at library level.
    Monday, April 15, 2013 8:54 AM

Answers

  • Adding library capabilities won't affect how FindFirstFileEx (or other Win32 API) work. The Win32 and C Runtime API require direct access to the file system and will work only on locations the app has full direct permissions for.

    Adding the Documents Library capability will allow reading declared file types from the documents library via the StorageItem classes. The capabilities and pickers enable access to otherwise prohibited locations via a broker process which opens the files on the app's behalf and returns the contents via StorageFiles and StorageFolders.

    --Rob

    • Proposed as answer by Jesse Jiang Thursday, April 18, 2013 2:21 AM
    • Marked as answer by Jesse Jiang Monday, April 22, 2013 3:02 AM
    Tuesday, April 16, 2013 7:16 PM
    Owner
  • In what way is this not working? What are the arguments that you are calling this with?

    As Keith says, FindFirstFileEx is supported in Windows Store apps so long as it is called in a directory that the app has permission to use directly: either the application data folder or the install directory. See File access and permissions for more information about where the app has permission to act directly.

    For folders that the app has only indirect access to (via StorageItem brokers returned by a file picker, library capabilities, etc.) you need to use the WinRT classes which work with the brokers. Take a look at FolderInformation.CreateFileQuery() and the Windows.Storage.Search namespace.

    I have discussed brokers previously in Skip the path: stick to the StorageFile

    --Rob

    • Proposed as answer by Jesse Jiang Tuesday, April 16, 2013 6:02 AM
    • Marked as answer by Jesse Jiang Monday, April 22, 2013 3:02 AM
    Monday, April 15, 2013 9:41 PM
    Owner

All replies

  • FYI: I'm using 'FindFirstFileExW' in a test App running  on 'x86' and it works fine within a folder contained in 'Windows::Storage::ApplicationData::Current->LocalFolder'. I haven't tried on ARM yet.

    Have you tried the same code on 'x86'?

    What error are you getting? (compile, link, runtime (INVALID_HANDLE_VALUE) ?

    Monday, April 15, 2013 12:31 PM
  • In what way is this not working? What are the arguments that you are calling this with?

    As Keith says, FindFirstFileEx is supported in Windows Store apps so long as it is called in a directory that the app has permission to use directly: either the application data folder or the install directory. See File access and permissions for more information about where the app has permission to act directly.

    For folders that the app has only indirect access to (via StorageItem brokers returned by a file picker, library capabilities, etc.) you need to use the WinRT classes which work with the brokers. Take a look at FolderInformation.CreateFileQuery() and the Windows.Storage.Search namespace.

    I have discussed brokers previously in Skip the path: stick to the StorageFile

    --Rob

    • Proposed as answer by Jesse Jiang Tuesday, April 16, 2013 6:02 AM
    • Marked as answer by Jesse Jiang Monday, April 22, 2013 3:02 AM
    Monday, April 15, 2013 9:41 PM
    Owner
  • when I try to execute 'FindFirstFileEx()' I am always getting 'INVALID_HANDLE_VALUE'. In function parameters I am passing Folder names("\\myfolder\\subfolder") as a 'findName' remaining as below

    fileFindData = new WIN32_FIND_DATA;
    hFind = FindFirstFileEx(findName.n_str(),FindExInfoStandard,(WIN32_FIND_DATA*)fileFindData,FindExSearchNameMatch,NULL,0);

    I already added 'Documents Library' in Capabilities and 'File type Associations' in Declarations.

    But I am calling this 'FindFirstFileEx function from a standard DLL(C/C++).

    Thanks & Regards,

    Murthy

    Tuesday, April 16, 2013 5:45 AM
  • To narrow the problem down, have you tried it on a folder within 'Windows::Storage::ApplicationData::Current->LocalFolder', and passed the full absolute path as the first parameter eg "C:\\Users\\...\\Packages\\...\\LocalState\\yourFolder\\subfolder\\*"

    Tuesday, April 16, 2013 7:07 PM
  • Adding library capabilities won't affect how FindFirstFileEx (or other Win32 API) work. The Win32 and C Runtime API require direct access to the file system and will work only on locations the app has full direct permissions for.

    Adding the Documents Library capability will allow reading declared file types from the documents library via the StorageItem classes. The capabilities and pickers enable access to otherwise prohibited locations via a broker process which opens the files on the app's behalf and returns the contents via StorageFiles and StorageFolders.

    --Rob

    • Proposed as answer by Jesse Jiang Thursday, April 18, 2013 2:21 AM
    • Marked as answer by Jesse Jiang Monday, April 22, 2013 3:02 AM
    Tuesday, April 16, 2013 7:16 PM
    Owner