Problem reading SMB OSX Sharing Files, they got corrupted by an extra 00 at the beginning and the lack of last pair
sergioabril opened this issue · comments
I'm trying libdsm under iOS, with the help of the great and simple wrapper made by @TimOliver (TOSMBClient), and I've found what I think is a bug with, maybe, smb_fread or smb_fopen
(I really hope I'm wrong and this has an easy solution).
When I try to explore and download files from a Mac with SMB OSX sharing enabled, I'm finding two problems. The first one, is that I can not go beyond 1st level. I mean, If I enter in //myMacName/MySharing I can see all the files and folders inside it; However, when I go and select one of those subfolders inside MySharing, like //myMacName/MySharing/folder1, the folder will appear as empty.
The second problem, and more important, is that when I try to download any file stored on /MySharing, it will be corrupted. Opening the downloaded file with an Hex editor, it has an extra 00 at the beginning and it lacks the last pair (compared to the original file). Why is this happening? So far, I only had this problem accessing my Mac, which is password protected (but I have no problems at logging in, since I can see all my personal folders listed).
The think is that, using the same code, if I access to my SMB NAS (raspberrypi), I have no problems at all, and everything works as expected.
Regards,
Sergio
@sergioabril have you done any progress on this ?
If not I'll have a look as I have the same issue !
Regards,
Sylver
@sylverb sadly I haven't, so let me know if you do any progress, please!
Best,
Sergio
I've found the root cause of the problem : there is an optional padding byte before the data in SMB_COM_READ_ANDX response (according to CIFS specification).
It says : Pad (1 byte): This field is optional. When using the NT LAN Manager dialect, this field can be used to align the Data field to a 16-bit boundary relative to the start of the SMB Header. If Unicode strings are being used, this field MUST be present. When used, this field MUST be one padding byte long.
I now have to find what exactly to check to be sure to make the right choice in all cases ...
Ok the solution is to use the "DataOffset" parameter in the response to know the position of data instead of using the structure ...
@sylverb nice job finding the problem and the solution ;-)! I'm more of a designer and light coder, so my knowledge of c and structures is very limited... I don't even know how I managed to compile libdsm :P
I'll start testing how to apply this solution soon and will come back if I get something
(any other practical hint or example code of how to proceed with that DataOffset, besides theoretical instructions? thank you though for this solution)
I've done a commit in my fork to solve the issue, I'll do a pull request soon !
The correction is as easy as changing one parameter in the memcpy call ...
Excellent job!