Not applicable

python sdk, upload with checksum has problem

Hi experts,

I'm using python 2.7 and atmos-python sdk (https://code.google.com/p/atmos-python/)

When I upload file with checksum I got error message : "There was a mismatch between the signature in the request and the signature computed by the server."

If I remove checksum, it upload ok.

How do I correct upload with checksum?


0 Kudos
1 Reply
3 Zinc

Re: python sdk, upload with checksum has problem


Please find the resolution for the above mentioned error:

Unfortunately, searching for this error message indicates it is a rather common error message for many REST related programming issues including the list below.

  • Programming errors in the REST API
  • Application errors
  • Applications that are down revision
  • Programming error in the Mime Types called by some REST APIs

For this reason, the fix can be hard to find and vary widely. The network is a great resource. Here are some other places to start.

1. If using EMC Atmos PHP wrappers, refer to EMC Knowledgebase solution [Link Error:UrlName "emc265903-Atmos-How-to-resolve-quot-unable-to-create-filenames-with-parenthesis-quot-using-PHP-wrappers" not found].

2. If using EMC EsuRestApi software, confirm if using a recent version.

3. If the REST application fails all of the time, there is probably an error in the program. In one case, the program was missing a " ) " and the mismatched " ( " was being sent as data. The error "There was a mismatch" was hit because the application in use did not support special characters such as " (  ".

4. If the REST application works fine when writing most file types such as .xml, .doc, or .jpg, but fails on one type such as a macro-enabled workbook with a .xlsm extension, there might be a programming error in the MIME Type utility. When using EsuRestApi software, each file type has its own MIME Type utility. In one case, the MIME Type utility used for .xlsm had a type-o. When the user changed the word "macroEnabled" to "macroenabled" (no Caps), it worked fine.

When this error is seen using the new Shareable Link feature in GeoDrive 1.1 and later.

In general, if the user does a copy and paste of the URL from the GeoDrive window into the internet browser, it will work fine. (as long as you do not have files with # in them)

In the example below, the coding error is in the URL string being used to access the data on the Atmos. The error was fixed by replacing the last character "=" (equals sign) in the URL with "%3D" (without quotes).

This command resulted in the "... mismatch ..." error:


This command ran without error and produced the output expected:



Suman Pinnamaneni

0 Kudos