none
SPException thrown during Add Document when file already exists

    Domanda

  • I am having unexpected results trying to upload a document to a library which is configured with No Versioning. 

    (i.e. the nature of this document collection is that each document is "personal" and should be unique; once stored, no need for "versioning").

    How can I configure things so that the end-user just gets a gentle slap on the wrist that says something like "Document already exists with that filename"? 

    • I click "Add Document" to Upload a Document
    • Uncheck the box labeled "Overwrite existing files" because:

    - user is intending to add a new file and does not want to "accidently" overwrite anything

    - user is unaware of all the files that have been previously uploaded

    • I click OK and get an unhandled exception with the advice to change web.config so customErrors mode="Off" but it already is set to Off (not "RemoteOnly"). This unfriendly response occurs when I am local on the machine or on another "remote" machine in the local intranet.
     Processing... 
    Please wait while your changes are processed. 
     
    
    
    --------------------------------------------------------------------------------
    
    Server Error in '/' Application.
    --------------------------------------------------------------------------------
    
    Runtime Error 
    Description: An application error occurred on the server. The current custom error settings for this application prevent the details of the application error from being viewed. 
    
    Details: To enable the details of this specific error message to be viewable on the local server machine, please create a <customErrors> tag within a "web.config" configuration file located in the root directory of the current web application. This <customErrors> tag should then have its "mode" attribute set to "RemoteOnly". To enable the details to be viewable on remote machines, please set "mode" to "Off".
    
    
    <!-- Web.Config Configuration File -->
    
    <configuration>
        <system.web>
            <customErrors mode="RemoteOnly"/>
        </system.web>
    </configuration> 
    
    • Windows Application Log follows:
    Event code: 3005 
    Event message: An unhandled exception has occurred. 
    Event time: 7/5/2012 3:15:12 PM 
    Event time (UTC): 7/5/2012 7:15:12 PM 
    Event ID: 3ed7b2ec20a94cc5b5bcf75e20730ef3 
    Event sequence: 583 
    Event occurrence: 4 
    Event detail code: 0 
     
    Application information: 
        Application domain: /LM/W3SVC/203489316/ROOT-1-129859658558606380 
        Trust level: WSS_Minimal 
        Application Virtual Path: / 
        Application Path: C:\inetpub\wwwroot\wss\VirtualDirectories\80\ 
        Machine name: BLACKTIP 
     
    Process information: 
        Process ID: 4304 
        Process name: w3wp.exe 
        Account name: CBMIWEB\spAppPool 
     
    Exception information: 
        Exception type: SPException 
        Exception message: A file with the name FlexiplaceAgreement03.pdf already exists. It was last modified by CBMIWEB\johna on 6/28/2012 5:56 PM. 


    John

    giovedì 5 luglio 2012 20:08

Risposte

  • Hi John,

    Oh the lovely CallStack value!  I should have caught that one as well, and that's what's causing the issue for you right there.  Switch it to CallStack="false" on your main web app, and you'll have the "soft" error.  I just tested it myself on a playground web app I've got, and switching the CallStack value to "true" results in the same ugly error you're seeing.  Switching it back to "false" gives me the "soft" error again.

    Setting customError="Off" and CallStack="true" is a common change made by developers or for error troubleshooting, but shouldn't be set on a production web app.  Production web apps should have customError="On" and CallStack="false".


    Mike Dalton
    SharePoint Barista
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot

    • Contrassegnato come risposta John.J.Adams venerdì 6 luglio 2012 21:44
    venerdì 6 luglio 2012 21:29

Tutte le risposte

  • Hi John,

    It sounds like either something or someone has broken your error handling.  I just replicated the scenario you described, and got a standard-looking SharePoint error dialog.  Do you have any custom or 3rd-party solutions deployed, or has anyone been playing around with the web.config?



    Mike Dalton
    SharePoint Barista
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot

    giovedì 5 luglio 2012 20:47
  • Hi Mike,

    Thanks for a quick reply. I agree this looks like non-standard behavior. I am the only one who logs on as sharepointAdmin. Going into Central Admin - Manage Farm Features, I see nothing unusual (all features are active): 

    Going to the site itself with my other personal id which is permitted as the site collection administrator, I see no Sandboxed solutions:

    Anywhere else I should look for presence of "custom" solution(s)? I am the only "developer" working here as far as I know.

    Is there some way to restore the standard error handling for something like this so I get a "softer" warning as you show above? 

     


    John

    giovedì 5 luglio 2012 21:46
  • Hi John,

    At this point it's difficult to tell exactly where the problem might be.  If you have the option of creating a new temporary web application in your farm, then that will get you a clean web app with a clean web.config file.  You can then try to duplicate the the "file already exists" issue to see what kind of error message format you get.  If you get the "softer" warning dialog, then it's a web application issue.  If you still get the ugly error page, then you're looking at something farm-level, .NET-level, or IIS-level.


    Mike Dalton
    SharePoint Barista
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot

    venerdì 6 luglio 2012 14:18
  • Thanks, Mike. Your troubleshooting approach makes sense to me and I should be able to make a new web application in the farm to test. I will get back to you with results of the test. If I get the "soft" msg, I hope there is something that can be done to chase the "web application issue". 



    John

    venerdì 6 luglio 2012 15:30
  • Mike, 

    I created a new web application followed by a site collection and then a new document library. I added FileName01.pdf to the library successfully. Then I tried to add the same file a 2nd time (i.e. specifically UNCHECKing the box labeled "Overwrite existing file"). 

    As you suspected, I got the "soft" warning dialog box / message - which is the proper behavior.

    Therefore, can you suggest any next move(s) to chase down the cause of this "web application issue" in my original web app: Sharepoint - 80 ?


    John

    venerdì 6 luglio 2012 17:19
  • Hi John,

    I have no idea how I missed it, but back in your very first post, you mentioned that the the following value was set:
    customErrors mode="Off"

    Try changing that to

    customErrors mode="On"

    And see if you start getting the "soft" dialogs again.  The custom error handling functionality is what allows SharePoint to intercept the nasty-looking error and wrap it in a nice dialog.  Switching customErrors to "Off" is typically a diagnostic mode, and having it set to "On" is more of a "production" mode.  You may need to manually recycle the application pool after making this change, or it may pick it up automatically.  Once the change is made, test it again to see what you get.


    Mike Dalton
    SharePoint Barista
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot


    venerdì 6 luglio 2012 18:12
  • Hi Mike,

    As I reported above, the newly created web app (using port 8080) spits out the "softer" error (telling me a file with the specified name already exists). 

    So, I went back to the original web app (using port 80) changed customErrors mode="Off" back to mode="On" - which is the same as the newly created test web app at port 8080. 

    To be sure, I manually recycled the application pool associated with that web application and unfortunately, I still DO NOT get the desired "soft error" reporting. In short, I get the same thing as in the original post. In summary, customErrors mode values of Off and On both result in the same response when this error is explicitly and intentionally introduced by me. 

    So I remain stumped.

    I used the Windiff utility to compare the following 2 directories and subdirectories:

    1. C:\inetpub\wwwroot\wss\VirtualDirectories\80
    2. C:\inetpub\wwwroot\wss\VirtualDirectories\8080

    Many files are identical of course. Web.config is different but not radically so; the only thing I noticed:

    <SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">
     

    The newly created web.config reads CallStack="false". Nothing else looks suspect to me.


    John

    venerdì 6 luglio 2012 20:22
  • Hi John,

    Oh the lovely CallStack value!  I should have caught that one as well, and that's what's causing the issue for you right there.  Switch it to CallStack="false" on your main web app, and you'll have the "soft" error.  I just tested it myself on a playground web app I've got, and switching the CallStack value to "true" results in the same ugly error you're seeing.  Switching it back to "false" gives me the "soft" error again.

    Setting customError="Off" and CallStack="true" is a common change made by developers or for error troubleshooting, but shouldn't be set on a production web app.  Production web apps should have customError="On" and CallStack="false".


    Mike Dalton
    SharePoint Barista
    Rackspace Hosting
    blog: mikedalton.net
    twitter: twitter.com/mikeelliot

    • Contrassegnato come risposta John.J.Adams venerdì 6 luglio 2012 21:44
    venerdì 6 luglio 2012 21:29
  • Thanks very much, Mike. 

    Indeed, changing CallStack from true to false led to proper "soft" error reporting. Your explanations along the way were much appreciated. 


    John

    venerdì 6 luglio 2012 21:46