locked
Windows Store C++ apps cannot create files using fopen() under Windows 8.1

    Question

  • We have several Windows 8 Store C++ apps that need to maintain configuration and data files.

    Files are written in subfolders of Windows::Storage::ApplicationData::Current->LocalFolder. Example:

    C:\Users\<username>\AppData\Local\Packages\<packagename>\LocalState\SubFolder1\SubFolder2\data.txt

    In Windows 8.1 we have received a few reports from users that say state isn't remembered between app invocations. Upon closer inspection the files are not created (the subfolders are indeed created, but there are no file contents)

    Notes:

    1. Subfolders are created using CreateDirectory(), files are created using fopen()

    2. Files are created/opened using absolute paths

    3. This always worked under Windows 8.0 and the code has not been changed since. In fact, one of our user reports stated that the app saved files fine under Windows 8.0, but stopped saving after the user upgraded to Windows 8.1.

    4. We have not been able to replicate the issue locally using Windows 8.1. We're not sure how common this failure is, but we estimate that most users are unaffected. Affected users do not appear to have any special hardware/software configuration.

    5. If a user is affected, then files are consistently never saved, even after retrying or uninstalling and re-installing the app (i.e., it's not a case of intermittent failure)

    6. It's hard to get error information given (i) the rarity of the issue (ii) the fact that the logs that would reveal this are by definition not saved, and (iii) the apps don't require internet connectivity so there is no alternative communication channel


    Can anyone think of any reason why this might fail under Windows 8.1?









    Wednesday, November 13, 2013 4:05 PM

Answers

  • Tracked down the problem: the user name (which forms part of the %LOCALAPPDATA% path) used extended ASCII chars, which got mangled in the conversion to 7-bit ASCII (expected by fopen). Replacing fopen calls with _wfopen did the trick.

    It was an unfortunate coincidence that the users upgrading from Windows 8.0 to 8.1 decided to also change their username, misleadingly pointing the finger at 8.1 (8.0 is equally affected)

    • Marked as answer by BETACOM S.A_ Tuesday, November 19, 2013 7:01 AM
    Tuesday, November 19, 2013 7:01 AM

All replies

  • Your app has access to its local data so fopen is valid there. Since it fails intermittently on some systems there is probably something on those systems interfering. The first thing I'd do to harden against this is to check for errors and then retry. It's possible that another program (such as anti-virus) has a reference open that temporarily blocks your call.

    --Rob

    Wednesday, November 13, 2013 7:16 PM
    Owner
  • Another thing to keep in mind is that fopen doesn't give you control over the sharing mode. You can make use of _fsopen to do this.


    Wednesday, November 13, 2013 8:34 PM
  • Thanks, Rob! To clarify, if a system is affected by this failure, then the failure is permanent and the files are NEVER saved. The failure is rare with respect to systems, but it is not temporally intermittent, so trying again on the same system will yield the same results.
    Thursday, November 14, 2013 9:10 AM
  • What error is reported?

    And when you say the problem is permanent are you always saving in the same place or are you delaying and trying again later after a failure? The former may consistently fail while the latter succeeds.

    --Rob

    Thursday, November 14, 2013 11:10 PM
    Owner
  • @Rob: By 'permanent' I mean that none of the expected 6 files are created, and they are still not created if the app is launched repeatedly, or if it is uninstalled and re-installed again. Each file is only saved at app launch/suspend/exit and at specific places in the code, but it's typical for each file to be saved multiple times throughout each app execution -- for example, at the end of each played game level (the apps are games).

    It's hard to get error information given (i) the rarity of the issue (ii) the fact that the logs that would reveal this are by definition not saved, and (iii) the apps don't require internet connectivity so there is no alternative communication channel.

    Friday, November 15, 2013 10:11 AM
  • I would definitely check for errors and then retry after a short delay if fopen (or _fsopen) fails.

    Friday, November 15, 2013 6:33 PM
    Owner
  • Tracked down the problem: the user name (which forms part of the %LOCALAPPDATA% path) used extended ASCII chars, which got mangled in the conversion to 7-bit ASCII (expected by fopen). Replacing fopen calls with _wfopen did the trick.

    It was an unfortunate coincidence that the users upgrading from Windows 8.0 to 8.1 decided to also change their username, misleadingly pointing the finger at 8.1 (8.0 is equally affected)

    • Marked as answer by BETACOM S.A_ Tuesday, November 19, 2013 7:01 AM
    Tuesday, November 19, 2013 7:01 AM