Gemaild zip bestand leeg bij aankomst

Waarom gebruik je geen kant en klare class om zip-bestanden te maken?

Als ik de code bekijk stuur je volgens mij alleen bestanden als attachment mee, zonder ze in te pakken en alleen met de .zip extensie erachter. Zo werkt dat niet.

Bevat $data na regel 7 inderdaad inhoud?

Ik mis een beetje de betekenis van $filedir in de eerste 7 regels van je script.
Wat bevat nu het path naar het bestand (incl. bestandsnaam)?


Zelf vind ik het wel eenvoudig om PHPMailer te gebruiken en dan te kunnen volstaan met

$mail->addAttachment($file)

[size=xsmall]Toevoeging op 04/01/2017 10:27:37:[/size]

$file = fopen($filedir,'rb');
$data = fread($file,filesize($filedir));
fclose($file); 

volgens mij bedoel je daar:

$file = fopen($filedir.$fileatt_name,'rb');
$data = fread($file,filesize($filedir.$fileatt_name));
fclose($file); 

of mogelijk

$data = file_get_contents($filedir.$fileatt_name);

En die zip-bestanden zijn handmatig gemaakt? In dat geval mag je mijn opmerking over 'de classes voor het maken van een zip-file' negeren.

$filedir is inderdaad het path. De zipt bestanden zijn inderdaad handmatig gemaakt. Als ik ze unzip zien ze er goed uit. Op het moment dat ik als bijlage verstuur ontvang ik zo ook alleen met 0 bytes.

maar in je huidige script lees je de file toch helemaal niet in?

fopen moet een filename als input hebben. Niet een directory

[size=xsmall]Toevoeging op 04/01/2017 12:12:43:[/size]

en mocht $filepath wel het path incl. de bestandsnaam bevatten:

Als de backup niet gemaakt is door Apache/PHP, dan kan die file zo maar staan op een plek die niet bereikbaar is (door de rechten) voor je PHP scipt.

is_readable() zou je dat kunnen vertellen.

Ziet er in eerste opzicht goed uit, maar waarom heb je Content-Disposition uitgecomment?

EDIT: weet trouwens niet of je op die manier een hele directory kunt grijpen.

Je kunt ook trouwens eenvoudig controleren of het bestand goed is overgekomen door de rauwe source van de e-mail te bekijken. Vervolgens zou je dat base64 blok kunnen copypasten en via een testscriptje ter download aan kunnen bieden om te kijken of deze mogelijk corrupt is geraakt.

EDIT: als er witregels tussen de base64 regels zitten dat moet je mogelijk de "line ending sequence" (derde parameter chunk_split) expliciet instellen op "\n". Default is dit namelijk "\r\n" wat voor teveel regelovergangen kan zorgen op sommige platformen.

En om te voorkomen dat je een regelovergang teveel aan het einde hebt wil je het resultaat van chunk_split wellicht nog trimmen. En als je slim bent vang je dit soort dingen in een functie:

<?php
function get_attachment($filename) {
    clearstatcache();
    if (file_exists($filename)) {
        $fp = fopen($filename, 'rb');
        $contents = fread($fp, filesize($filename)); // @todo remember to fix zero-length files
        // note that chunk_split also adds an "end" character sequence at the end of the string, hence rtrim
        return rtrim(chunk_split(base64_encode($contents), 76, "\n")); // @todo 3rd parameter might depend on platform
    } else {
        return false;
    }
}
?>

Je zou een tussenstap kunnen inbouwen waarin je de directory eerst ergens zipt, en dan als attachment toevoegt?

Maar ook die functie zal niet werken als je daar niet de filename ingooit.

Dat is namelijk wat in het oorspronkelijke script ook niet gebeurt.

Filename heb ik aangepast. Door jullie hulp heb ik de zaak nu werkend. De mail wordt verzonden alleen in het format zoals hierna wordt getoond. Ik moet nog uitzoeken hoe ik dat in het juiste formaat krijg.
Vast bedankt voor al jullie opmerkingen en hulp. Weer veel van geleerd. ;).
Peter

Content-Type: application/octet-stream; name=database.sql

Content-Transfer-Encoding: base64

Content-disposition: attachment


DQojQ3JlYXRlIHRhYmxlIGFjdGllZg0KDQpDUkVBVEUgVEFCTEUgYGFjdGllZmAgKAogIGBhY3Rp

ZWZfaWRgIGludCgxKSBOT1QgTlVMTCwKICBgYWN0aWVmX29tc2AgdmFyY2hhcigxNSkgTk9UIE5V

TEwKKSBFTkdJTkU9SW5ub0RCIERFRkFVTFQgQ0hBUlNFVD1sYXRpbjE7DQoNCiNEdW1wIGRhdGEN

Cg0KSU5TRVJUIElOVE8gYWN0aWVmIFNFVCBhY3RpZWZfaWQ9JzAnLGFjdGllZl9vbXM9J25pZXQg

YWN0aWVmJzsNCklOU0VSVCBJTlRPIGFjdGllZiBTRVQgYWN0aWVmX2lkPScxJyxhY3RpZWZfb21z

PSdhY3RpZWYnOw0KDQojQ3JlYXRlIHRhYmxlIGJhY2t1cA0KDQpDUkVBVEUgVEFCTEUgYGJhY2t1

cGAgKAogIGBiYWNrdXBfaWRgIGludCgxMSkgTk9UIE5VTEwgQVVUT19JTkNSRU1FTlQsCiAgYGRh

dHVtX2xhc3RfYnVgIGRhdGUgTk9UIE5VTEwsCiAgYGRhdHVtX25leHRfYnVgIGRhdGUgTk9UIE5V

TEwsCiAgYGtsYW50X2lkYCBpbnQoMTEpIE5PVCBOVUxMLAogIGBidV9uYW1lYCB2YXJjaGFyKDYw

KSBOT1QgTlVMTCwKICBgYnVfcGFkYCB2YXJjaGFyKDYwKSBOT1QgTlVMTCwKICBgYnVfbWFpbF90

b2AgdmFyY2hhcig2MCkgTk9UIE5VTEwsCiAgYGRhdHVtYCB0aW1lc3RhbXAgTk9UIE5VTEwgREVG

QVVMVCBDVVJSRU5UX1RJTUVTVEFNUCwKICBQUklNQVJZIEtFWSAoYGJhY2t1cF9pZGApCikgRU5H

SU5FPUlubm9EQiBBVVRPX0lOQ1JFTUVOVD0yIERFRkFVTFQgQ0hBUlNFVD1sYXRpbjE7DQoNCiNE

Dat zeg ik dus:

EDIT: als er witregels tussen de base64 regels zitten dat moet je mogelijk de "line ending sequence" (derde parameter chunk_split) expliciet instellen op "\n". Default is dit namelijk "\r\n" wat voor teveel regelovergangen kan zorgen op sommige platformen.

Dank voor alle info.
Peter