Trying To Delete Scratch Files Left Behind By Mike Clarks's Azure File Sync Provider RRS feed

  • Question

  • The code below is from the Azure File Sync Provider on codeplex.  Basically, what it is doing is getting a handle to a file stream, then passing that handle (stream) to FileRetriever, which then returns it to the Sync Framework by way of the overridden class LoadChangeData (as changeData).  The problem is that the temp file create is still there and accumulates in the temp directory forever.  One easy way around this would be to do a deep copy of the file stream to a byte array, then return that as a MemoryStream allowing us to delete the temp file.  The problem with doing that is MemoryStream is limited to 4gig and since the fileprovider can handle more than that (I know because I tested it), MemoryStream is not a satisfactory solution.

    So, is there a hook someplace that I can get a hold of that let's me know when the file provider has copied that one file?  I'm a little nervous that there can not be because the changes are batched.  Say the user wants to copy 10 5 gig files, that might mean they need to keep 50gig of scratch files around.

    Before I get carried away with what if's, What is the best way around this problem?


    if( !bool.Parse(blob.Metadata[AzureBlobStore.IsDirectory]) )
            // Special handling for directories
            stream = File.OpenRead(tempFileName);
            size = long.Parse(blob.Metadata[AzureBlobStore.SizeKey]);
          pathWithName = blob.Metadata[AzureBlobStore.PathWithNameKey];
          // Note that the IsDirectory property for the FileData object is pulled from the Attributes 
          FileData fd = new FileData(
          return new FileRetriever(fd, relativePath, stream);

    Peter Kellner Microsoft MVP • ASPInsider
    Saturday, December 4, 2010 3:01 AM

All replies

  • One possibility I've been experimenting with is to open the file with the option DeleteOnClose.  It's a little scary though to do this not knowing what is really happening inside the file provider.  Could someone on the team who has eyes on that source comment if this is a reasonable solution? It seems to work but I don't want to go on a hunch.

    Thanks, or any other ideas, please chime in.

    fileStream =


    new FileStream(fileToDownload, FileMode.Open, FileAccess.Read,FileShare.ReadWrite,1024*1024,FileOptions.DeleteOnClose);

    Peter Kellner Microsoft MVP • ASPInsider
    Monday, December 6, 2010 11:16 PM