CopyFromBlob error RRS feed

  • Question

  • OK, this should be really easy, but it isn't working.  Here's the line that is giving me an error


    Both 'renamedblob' and 'blob' have been defined like so:

    blob = container.GetBlobReference(blobPath + newFileName);

    renamedblob = container.GetBlobReference(blobPath + renamedfilename)

    I can put a breakpoint in code and see properties and the URL for each of them.  I can also go into Azure Storage Explorer and see the source blob (blob) in my container.  The container is set to 'Public container'

    Yet the code above gives me the error "The specified blob does not exist" with an internal error of

    {"The remote server returned an error: (404) Not Found."}

    Can anybody give me any hints on how to troubleshoot this?



    Friday, May 10, 2013 4:03 PM


  • I give up...I tried replicating the issue in all versions I have starting with 1.6 up to 2.0...in fact 2.0 does not have CopyFromBlob...but its async counterpart...just one suggestion...you can use container name without forward slash (/) and it will still work...though it does not matter...but who knows..if that fixes the issue...
    Sunday, May 12, 2013 3:57 AM

All replies

  • Please check the value of AbsoluteUri and also hit this in browser to see if the blob is getting downloaded. It seems like the issue with blob uri...probably because of blobpath+ being used.
    Friday, May 10, 2013 5:09 PM
  • Thanks for the response.

    The absolute Uri is correct.  That is, I can put a break in the code and grab the AbsoluteUri from the Watch Window for the object 'blob' and then paste that Uri into internet explorer, and it works.  I just did it and here it is:


    It's an appointment file and the 'appointments' container is public.

    But for some reason, when I try to copy this to another blob, with a different name, it gives me the error.

    Any ideas why that might be?

    Just FYI, the goal here is this: If I try to upload a file with the same name as one that already exists, it should rename the one that is already out there and then upload the new one without changing its name.

    Friday, May 10, 2013 5:28 PM
  • I did simple six lines and was successful in copying blob...so I still feel there is some issue with blob uri...please confirm if the other blob uri is also available.

    CloudStorageAccount csa = CloudStorageAccount.Parse(RoleEnvironment.GetConfigurationSettingValue("Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString")); CloudBlobClient cbc = csa.CreateCloudBlobClient(); CloudBlobContainer cbcr = cbc.GetContainerReference("testcontainer"); CloudBlob cbb = cbcr.GetBlockBlobReference("screen5.png"); CloudBlob cbb2 = cbcr.GetBlockBlobReference("screen1.png"); cbb2.CopyFromBlob(cbb);

    Friday, May 10, 2013 6:46 PM
  • Do one thing before you call copyfromblob...make FetchAttributes() method call for both CloudBlob objects renamedBlob and Blob...this is actual hit to storage account to fetch the details of the blob stored...this will validate if the blobs are good and available.
    Friday, May 10, 2013 6:52 PM
  • 1) In regards to the renamedBlob, the blob itself doesn't actually exist yet at the time of the error, but the URL appears to be valid, which I copied below:


    2) I am already called the FetchAttribute() method in part of a routine that checks whether the blog exists. 

    Again, I appreciate your effort.  You are suggesting stuff that makes sense, but I believe I've already considered it.  Maybe it's something obvious that I'm missing, but I can't find it.

    One thing I just noticed. The link above has 'https', but the link I see in Storage Explorer just shows 'http'. Let me check if that is the problem.

    FYI, here is the full method:

            public void RenameExistingBlob(string blobPath)
                    int iname = 0;
                    string renamedfilename;
                    FileInfo fileInfo = new FileInfo(newFileName);
                    string fileExtension = fileInfo.Extension;
                    string fileNameNoExtension = newFileName.Replace(fileExtension, "");
                    CloudBlob renamedblob;
                        renamedfilename = String.Format("{0}-Prior{1}", fileNameNoExtension, iname.ToString()) + fileExtension;
                        renamedblob = container.GetBlobReference(blobPath + renamedfilename);
                    } while (renamedblob.Exists());
                catch (StorageClientException ex)
                    //Sometimes, it can't find the existing blob to peform the copy, so we'll just overwrite current file 
                catch (Exception ex)

    Friday, May 10, 2013 6:59 PM
  • I looked in the 'http' versus 'https' and I don't think that is causing a problem.  When I check things manually using IE, it doesn't appear to matter which one I use.

    It is curious that when I create the container in code, it creates a new blob with the 'https'.  But when I view the created blob in Storage Explorer, it shows that blob with just 'http'.

    Friday, May 10, 2013 7:09 PM
  • I do not see any issue in the code...do one last thing for me...before calling CopyFromBlob() method call, just make one call...blob.FetchAttributes()...just to verify if the blob is not lost...as it is not mandatory to have a valid (existing) renamedblob...so it is something to do with other blob object...just trying to think loud...as I tried the code with all combinations and it is working perfectly fine for me every time though.
    Friday, May 10, 2013 7:44 PM
  • To answer you question about http and https...in code your connection string must be configured starting with DefaultEndpointsProtocol=https; and that's why https.
    Friday, May 10, 2013 7:59 PM
  • I tried blob.FetchAttributes() and it didn't help.  The command worked fine, but it didn't solve the error.

    Here's one other strange fact.  This code works for some other containers.  Those containers are private, and I use credentials to access them.  This container ("appointments") is public.  Also, the structure of the file names is different in those other situations.  None of that would seem to make any difference.

    So, I'm about to give up.  I appreciate your effort and suggestions, but I don't know what else to try.

    If you have other thoughts, I'd be glad to hear them, but I don't expect you to keep dealing with it.



    Friday, May 10, 2013 8:49 PM
  • Last thing before I give up...please share two things

    statement for creation of container object used above...and also the value of blobpath.

    Saturday, May 11, 2013 5:09 AM
  • I had been using Windows.WindowsAzure.StorageClient version and decided I should probably upgrade to Windows.WindowsAzure.Storage version, regardless of this current issue.

    So, now I'm busy fixing references and breaking changes.  It's turning out to be more of an upgrade than I anticipated.

    And so I still don't know whether it will fix the problem.

    In answer to your questions:


    blobpath="" (empty string)

    Saturday, May 11, 2013 1:10 PM
  • I give up...I tried replicating the issue in all versions I have starting with 1.6 up to 2.0...in fact 2.0 does not have CopyFromBlob...but its async counterpart...just one suggestion...you can use container name without forward slash (/) and it will still work...though it does not matter...but who knows..if that fixes the issue...
    Sunday, May 12, 2013 3:57 AM
  • Yeah, I have the same issue and I'm giving up on it too. if you follow the code listed here: http://msdn.microsoft.com/en-us/library/jj933290.aspx from the section of 

    Copying Blobs from a Storage Account Associated with Media Services Account into a Media Services Asset

    You'll get the the same error. Frustrating working with something that just basically does not work. I am going to have to punt as well. Because we are trying to actually deliver business value instead of fighting with an api that is just not working. I will have to come up with another way of doing it without using azure storage to hold my files that will be imported into azure. I was trying to move all this to the cloud, but this is one part that just has me stopped dead.

    Thursday, May 23, 2013 3:45 AM