Data loss when downloading data from LDAP server
Posted
by Ricky D'Amelio
on Stack Overflow
See other posts from Stack Overflow
or by Ricky D'Amelio
Published on 2010-03-20T02:29:18Z
Indexed on
2010/03/20
2:31 UTC
Read the original article
Hit count: 483
Hi there. This question comes from a previous one I asked about handling NSData objects: http://stackoverflow.com/questions/2453785/converting-nsdata-to-an-nsstring-representation-is-failing.
I have reached the point where I am taking an NSImage, turning it into NSData and uploading those data bytes to the LDAP server. I am doing this like so;
//connected successfully to LDAP server above...
struct berval photo_berval;
struct berval *jpegPhoto_values[2];
photo_berval.bv_len = [photo length];
photo_berval.bv_val = [photo bytes];
jpegPhoto_values[0] = &photo_berval;
jpegPhoto_values[1] = NULL;
mod.mod_type = "jpegPhoto";
mod.mod_op = LDAP_MOD_REPLACE|LDAP_MOD_BVALUES;
mod.mod_bvalues = jpegPhoto_values;
mods[0] = &mod;
mods[1] = NULL;
//perform the modify operation
rc = ldap_modify_ext_s(ld, givenModifyEntry, mods, NULL, NULL);
That happens with no errors, and you can see a big blob of data when you're in the command line.
My problem is, when I go to access the same data at a later stage, I am getting an image file back that's about 120 times smaller than the original image.
//find the jpegPhoto attribute
photoA = ldap_first_attribute(ld, photoE, &photoBer);
while (strcasecmp(photoA, "jpegphoto") != 0)
{
photoA = ldap_next_attribute(ld, photoE, photoBer);
}
//get the value of the attribute
if ((list_of_photos = ldap_get_values_len(ld, photoE, photoA)) != NULL)
{
//get the first JPEG
photo_data = *list_of_photos[0];
selectedPictureData = [NSData dataWithBytes:&photo_data length:sizeof(photo_data)];
[selectedPictureData writeToFile:@"/Users/username/Desktop/Photo 2.jpg" atomically:YES];
NSLog (@"%@", selectedPictureData);
Has anyone successfully done this before or can anyone see what I might be doing wrong? I appreciate anyone's help. Sorry to post so many questions!
Ricky.
© Stack Overflow or respective owner