locked
C++ File I/O is not session-safe in web applications RRS feed

  • Question

  • User24360312 posted

    A C++ object is instantiated for each user session in an ASP.NET web application running on IIS (the application is built using the multi-threaded C-Runtime libraries). The C++ object performs file output related to the current user session using fopen(), fprintf(), and fputs(). The output file for each user session has a unique name. The Problem: The contents of a user's file also contains output from other user sessions that are running concurrently. So, either these file stream functions are not safe to use in a multi-session application running on IIS (i.e., not compatible with IIS/ASP.NET process & thread management), or there is some undocumented setup required to use them in this environment. Please offer suggestions on how to resolve this problem.

    More Information: The FILE* returned by fopen() is saved as a private class variable, and so is the unique filename. The C++ object is instantiated in Session_Start(), so each user session will have its own copy of these variables. Problem is, I observed that fopen() returns the same value for a specific FILE* in each session, even though the filename is different, which indicates that the Windows OS code behind fopen is using the same internal file handle/buffer, and does not operate properly between sessions. Normally, each fopen will return a different value for FILE* corresponding to the value assigned by the internal Windows functions, until a matching fclose releases this handle/buffer slot.

    Therefore since fprintf() writes to the output file based solely on the value of the FILE* passed to it, and the FILE* contains the same value for each session regardless of what filename is used to open it, wouldn't this be the cause of my problem? Is this happening because one user's session may run on different worker processes at any give time, and a file created in one worker process is not accessible in a different worker process?

    Friday, September 21, 2012 9:48 PM

Answers

  • User-1002157272 posted

    If this is appearing to only be a problem with the asp.net/IIS integrated pipeline, I'm wondering if it has something to do with IIS in particular and the NT User it's operating under. I wish I had a helpful way to check this for you but I've never attempted what you're doing.

    Very clever idea by the way :) I'd be very interested to chat about the general implementation of your approach sometime. Your idea definitely got the hamster wheel spinning in my head! lol

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, October 6, 2012 12:37 AM

All replies

  • User1109032460 posted

    You'll have no luck if you are using multiple processes with this approach.

    You're almost certainly better off opening, writing and closing the file each time you want to use it, rather than attempting to hold a pointer in memory in a Session object.

    Monday, September 24, 2012 2:29 PM
  • User24360312 posted

    The "open/write/close" approach appears to work better, but how can I be confident that the file output in one session will complete before another session interrupts it? If this happens, then even the suggested approach will not prevent the problem from occurring, will it?

    File I/O seems to work fine with multiple processes, just not with the IIS/ASP.NET model. Hence the title of my post. I've seen no documentation that warns developers of this, and it's not something that can be considered obvious. I vote to call it a "bug". How do I elevate this to Microsoft's attention?

    Thursday, September 27, 2012 11:52 AM
  • User-1002157272 posted

    If this is appearing to only be a problem with the asp.net/IIS integrated pipeline, I'm wondering if it has something to do with IIS in particular and the NT User it's operating under. I wish I had a helpful way to check this for you but I've never attempted what you're doing.

    Very clever idea by the way :) I'd be very interested to chat about the general implementation of your approach sometime. Your idea definitely got the hamster wheel spinning in my head! lol

    • Marked as answer by Anonymous Thursday, October 7, 2021 12:00 AM
    Saturday, October 6, 2012 12:37 AM