IFile.Length vs ByteArray.Lenght

[Gareth064]

Hi
I'm looking for some advice here.

I have a service which moves documents from one Site to another. In short, to move the file, I simply create a new file in the target location using the bytes of the original file. But then I do a check to see if the length of the new file and the original are different. If they are then I throw an error because it could mean there is corruption somewhere in the new file.

Here is what I am doing (code stripped down for brevity)

//get file binary of the original file
byte[] byteArray = fileToMove.GetContentBytes();

//create the new file in the destination site/folder using the byteArrary
IFile? movedFile = null;
movedFile = docFolder.Files.Add(
    movedFileUrl,
    new MemoryStream(byteArray)
    {
        Position = 0
    }
);

//Check file length is not less than original
var movedFileLength = movedFile.Length;
if (movedFileLength < byteArray.Length)
    {
        movedFile.Delete();
        throw new ApplicationException($"Move failed. SharePoint uploaded file size: {movedFileLength} Bytes was unexpectedly smaller than previous file size {byteArray.Length} Bytes.");
    }

That last part of the code.... should I be comparing the Length property of the newly created file against the Length of the byteArray from the original file?

99% of the time they match and everything is merry, but the other 1% they don't match and the new file length value is smaller, so it throws the error.

Problem is, we deal with possibly 1k+ documents per day through this service, so the 1% is still a hearty number of failures.

As I have been writing this, and got this far, I am now thinking I should change the lenght check to the following

var movedFileLength = movedFile.GetContentBytes().Length; //<<< Getting the ContentBytes of the new file to compare?
if (movedFileLength < byteArray.Length)
    {
        movedFile.Delete();
        throw new ApplicationException($"Move failed. SharePoint uploaded file size: {movedFileLength} Bytes was unexpectedly smaller than previous file size {byteArray.Length} Bytes.");
    }

Advice on this would be great. Even if that advice is "You don't need to worry about checking, it never corrupts :D"

[jansenbe]

@Gareth064 : Not sure on the lengths....did you manually inspect the 1% with a length delta?

What I typically do is calculate a checksum of the source and target files and compare that...it should be identical. This implies you're pulling down the file from the target again, so performance wise that might have an impact especially if you're dealing with very large files

[Gareth064]

With this code, is it not creating the new file in SPO and then populating the movedFile variable with it? As in, its created it then fetched it at the same time?

IFile? movedFile = null;
movedFile = docFolder.Files.Add(
    movedFileUrl,
    new MemoryStream(byteArray)
    {
        Position = 0
    }
);

[jansenbe]

to really verify fidelity of the uploaded file you should fetch it again in my opinion

[Gareth064]

Hmm ok. I will have to figure out how I can test the impacts if I was to fetch the file again. The volume going through production is very high but non-production hasn't got any volume going through it unless we manually trigger processes in other systems.

I also need to understand if I even need to do this. I have rewritten an old .net framework service which was putting the files into SP 2019 on prem. My version is the latest .net and targeting SPO. A lot of my code approaches and logic is taken from this other 6 year old service so things are likely more resilient these days when creating a file in SPO.

[jansenbe]

@Gareth064 : yes, in the idea is that you can trust the upload, if it failed somehow you should have gotten an exception. Whether you want to include this extra check is something to optionally add