Much larger destination files (null padded)

[akaltani]

I'm not sure if this is supposed to be this way, but it seems that when I try downloading any file, the file is null padded to a larger size. I searched this up, and I believe it has something to do with 'speculative preallocation'

Now, is this a known property of samba, or is there a workaround to get the original with same file size? (besides manually truncating)

My issue seems to be with text files (images seem to work fine either way). If I have a really small text file, let's say 40 bytes in size. The new text file that has been downloaded is now the original 40 bytes, with an additional ~100,000 null bytes

When reading out this file, I have the contents of the file being printed out twice, which I am assuming is because of the null characters.

Could anyone explain why this is, or if there is anyway around it?

Thanks

[akaltani]

So I did fix my text file issue by truncating after the fact, but would still be interested to know why this is.

Issue can otherwise be removed

[TimOliver]

Just to get the terminology straight (As far as I understand it!), nothing here is related to Samba. Samba is another open source library built around the SMB/CIFS protocol, but it's unusable on iOS because of its restrictive licensing (Hence why libdsm and TOSMBClient exist in the first place). :)

Hmmm, so at the moment, this library just loops through a do loop, reading bytes out of libdsm until there are no more bytes to read. If the SMB session decides to include a batch of null bytes at the end, this library wouldn't be accounting for them.

As far as I know, you're guaranteed to know the size of the file ahead of time, so it might just be a matter of ensuring the number of bytes read doesn't exceed that number.

I'll have to run some tests on my own to see if that's actually the case. :)

[akaltani]

Ah yes. I was referring to the libdsm library. Regardless of why I didn't write that, still relatively new to all these terms and it's nice to have everything cleared up!

Now, if a fix were in fact to be implemented, I'd assume it'd best go to libdsm if anything as you said, but again, don't know if this is a feature or a bug

That said, my workaround for the meantime is to truncate the file after it's been downloaded. Your client seems to recognize the correct number of bytes, so as of now, I honestly have no clue where this 'feature' or 'bug' is coming from

Lastly, thanks for the amazing client! Works wonderfully indeed

[natalia-osa]

I have similar problem. The original file is 97KB, the downloaded one 197KB. That's a zip file. I can uncompress in on my OS X, but I cannot do it correctly on iOS (SSZipArchive). Probably also will have to truncate the file, however in my case it is not null padded. First 97KB is equal to the original file, then there's some random HEX written - not nulls.
Maybe it would be a good idea to truncate the file before calling 'completion' block, inside the library? If so, I may help with temporary PR, until it gets fixed in libdsm :).
Otherwise, for anyone else coming into this issue, quick fix is to call this at your downloadTaskForFileAtPath:destinationPath:progressHandler:completionHandler:failHandler: completionHandler block:

NSData *fileData = [[NSFileManager defaultManager] contentsAtPath:filePath];
if (fileData.length > fileSize) {
    NSData *onlyReqiredData = [fileData subdataWithRange:NSMakeRange(0, fileSize)];
    BOOL didOverrideFile = [onlyReqiredData writeToFile:filePath atomically:YES];
    if (!didOverrideFile) {
        NSLog(@"SMB download: The file was bigger than expected. We were unable to cut the spare rest of the file (at path: %@).", filePath);
    }
}

[narendra-ct]

@natalia-osa by the way with the following code Im able to fix the zip issue.

while ((bytesRead < self.file.fileSize))
{
@autoreleasepool {

    length = smb_fread(self.downloadSession, fileID, buffer, bufferSize);
    if (length != -1)
    {
        bytesRead += length;
        [fileHandle writeData:[NSData dataWithBytes:buffer length:length]];

        //Ensure the data is properly written to disk before proceeding
        [fileHandle synchronizeFile];

        self.countOfBytesReceived += length;

        [self didUpdateWriteBytes:length totalBytesWritten:self.countOfBytesReceived totalBytesExpected:self.countOfBytesExpectedToReceive];
    }
}

}