Vreemde unlink problemen: kan niet wissen

[MrDummy]

Ik ben bezig met een website.
Daar heb ik backup script gebruikt voor database.
Dat is deze: http://www.htmlcenter.com...-mysql-database-with-php/

Maar na afloop moet het ook verwijderd kunnen worden.
Hiervoor heb ik script gemaakt:

PHP:

<p>Reeds gemaakte backups:<br />

<? 
$files = glob('backup/*.sql');

if (count($files))
    {
    foreach ($files as $value) 
        {
    ?>
<a href="<? echo $value; ?>"><?=$value;?></a> <input type="submit" name="deletefile|<?=$value;?>" value="Delete this file" />
    <?
        }
    }
    else
    {
    echo "No backup files found.";
    }
?>
</p>

en verwerking is deze:

PHP:

if (array_search_bit("deletefile|", $_POST)) 
    { 
    $key=array_search_bit("deletefile|", $_POST); 
    list($action,$file)=explode("|",$key);
    }

if ($action=="deletefile")
    {
    $fullfile = $_SERVER['DOCUMENT_ROOT'] . "/" . $file;
    if (is_file($fullfile)) { echo "IsFile"; } else { echo "NotFile"; }
    unlink($fullfile);
    $result.="File ".$fullfile." is deleted.<br />";
    }

Ik heb problemen getest op raspberry webserver en op windows pc met XAMPP server.
Beiden geven identieke problemen van unlink probleem.

In Windows krijg ik melding "No such file or directory"
In Raspberry webserver krijg ik geen melding, maar er is wel "NotFile" melding bovenaan door is_file.
De absolute paths zijn in orde.
De files zijn linkbaar in de pagina en kan ik downloaden.

De chmod waarde van file op raspberry blijkt op 644 te staan. De directory backup is op 777 ingesteld, want file aanmaken gaat wel goed en kan ik downloaden. Wissen kan wel vanuit FileZilla, maar dat is niet de bedoeling. Maar chmod met Filezilla mislukt en blijft op 644 staan.

Rest mij alleen de vraag - want ik heb alle problemen op website nagetrokken - maar veel punten zijn goed ingesteld, alleen ik ben niet duidelijk waar de probleem precies is, want de probleem is ook aanwezig op makkelijkere Windows server waar bestand wissen geen probleem moet zijn.

Er is hier misschien 1 reden: de verkeerde user permissie. Maar waarom doet Windows ook niet?

Je mag je mening geven wat je zelf denkt over mijn probleem.

[ Voor 3% gewijzigd door MrDummy op 18-11-2015 15:39 ]

[DJMaze]

PHP:

echo $fullfile;

[MrDummy]

DJMaze schreef op woensdag 18 november 2015 @ 16:17:

PHP:

echo $fullfile;

Hier kan ik niks mee zonder uitleg. Sorry, het is geen goede reactie.
Wat is met de code? Vergeten? Nee, ik krijg prima output voor.

Bij windows begint het netjes met C:\ enzo
Bij raspberry begint het met /var/www/ enzo

Ik heb script BigDump ontdekt en even voor test op server geset. Er zit ook unlink in, en al snel blijkt dat het wel werkt zonder foutmelding. Dus ik moet uitzoeken wat er precies in unlink gaat van BigDump.

Update:
BigDump code nagekeken naar hele bestandsnaam, dit overgenomen in script boven, even getest, en drommels, dezelfde foutmelding staat er weer. Ik weet ook niet meer waarom BigDump wel doet. Alleen er zit wel @unlink in en niet unlink. Maar dat zou toch niet veel uitmaken!
Mogelijk is er wat vooraf in BigDump zodat het wel goed gaat.

[ Voor 68% gewijzigd door MrDummy op 18-11-2015 18:14 ]

[TheRookie]

getest, als in na de aanroep van unlink in "BigDump" is het bestand ook daadwerkelijk weg ?

@ heeft een betekenis:

quote: http://php.net/manual/en/language.operators.errorcontrol.php

PHP supports one error control operator: the at sign (@). When prepended to an expression in PHP, any error messages that might be generated by that expression will be ignored.

[DJMaze]

MrDummy schreef op woensdag 18 november 2015 @ 18:03:
Hier kan ik niks mee zonder uitleg. Sorry, het is geen goede reactie.
Wat is met de code? Vergeten? Nee, ik krijg prima output voor.

Bij windows begint het netjes met C:\ enzo
Bij raspberry begint het met /var/www/ enzo

Tweakers is om je op weg te helpen en niet om de oplossing te geven.
Ik gaf je daarom die ene lijn die jou een gigantisch eind op weg zou moeten helpen.

Als je die echo deed kwam je er achter dat de '.' (punt) niet bestaat in je $file.
PHP past namelijk in $_POST/$_GET keys aan met '_' (underscore).
http://php.net/manual/en/...iables.external.php#81080

Aangezien bestanden meestal een punt bevatten was je probleem dus direct zichtbaar.

Zeg dus niet dat je niks met mijn reactie kon, dat kon wel degelijk als je het probeerde en je ogen open had.

spoiler: gebruik base64

<a href="<? echo $value; ?>"><?=$value;?></a> <input type="submit" name="deletefile|<?=base64_encode($value);?>" value="Delete this file" />

en...

$file = base64_decode($file);

[ Voor 18% gewijzigd door DJMaze op 19-11-2015 12:55 ]

[MrDummy]

DJMaze schreef op donderdag 19 november 2015 @ 11:39:
[...]
Als je die echo deed kwam je er achter dat de '.' (punt) niet bestaat in je $file.
PHP past namelijk in $_POST/$_GET keys aan met '_' (underscore).
http://php.net/manual/en/...iables.external.php#81080

Ah, dat heb ik niet op voorzien, want zoiets heb ik niet eerder meegemaakt na jaren programmeren. Alleen pas vandaag met filename in $_POST gaan werken, en zo'n klein detail heb ik niet op voorzien.

Nu weet ik het, en dat zal ik ook onthouden als ik weer zoiets ga doen en ook zoiets later gaan doen met bestanden in andere websites. Voor uploaden bestand gebruik ik $_FILES. Bij doorgeven van alleen bestandnaam in de variabele naam moet dus eerst vooraf omgezet worden. Natuurlijk is waarde zelf geen probleem.

Sorry voor ongemak met erg korte reactie, op één teken als detail duurt het lang om door te hebben. Was de uitleg even erbij dat er een probleem is met $_POST in omgang met punten, dan kan ik naar kijken en zoek ik meteen de oplossing op om punt probleem te verhelpen.

In BigDump valt het niet meteen op omdat het gebruik maakt van $_REQUEST. Daar is geen base64_encode van gebruikt in BigDump. Ik vraag me af waarom daar wel doet en niet hier.
En: elders in script is urlencode gebruikt voor $_REQUEST, maar voor data lezen vanuit $_REQUEST kan dus direct.

Verder gezocht is er ook mooi informatie:
http://stackoverflow.com/...ers-in-get-or-post-arrays
met diverse oplossingen...
Zie verder dat het ook geldt voor $_REQUEST.
(staat bijvoorbeeld in http://stackoverflow.com/...7622/dot-in-variable-name)

Hartelijk bedankt voor de leerzame informatie.

[ Voor 8% gewijzigd door MrDummy op 19-11-2015 15:45 ]

[Gomez12]

Give a man a fish, teach a man to fish...

MrDummy schreef op donderdag 19 november 2015 @ 15:34:
[...]
Sorry voor ongemak met erg korte reactie, op één teken als detail duurt het lang om door te hebben. Was de uitleg even erbij dat er een probleem is met $_POST in omgang met punten, dan kan ik naar kijken en zoek ik meteen de oplossing op om punt probleem te verhelpen.

In wezen was in dit geval de uitleg niet nodig geweest, 1 van de 1e stappen van debuggen is gewoon kijken of wat er staat wel echt is wat je verwacht, had je dat gedaan dan was het gelijk opgevallen.

Dit was blijkbaar gewoon een poging om je te leren hoe je moet debuggen, maarja als jij dat niet wilt en enkel helpdeskje wilt...

[DJMaze]

Gomez12 schreef op donderdag 19 november 2015 @ 23:41:
In wezen was in dit geval de uitleg niet nodig geweest, 1 van de 1e stappen van debuggen is gewoon kijken of wat er staat wel echt is wat je verwacht, had je dat gedaan dan was het gelijk opgevallen.

Dit was blijkbaar gewoon een poging om je te leren hoe je moet debuggen, maarja als jij dat niet wilt en enkel helpdeskje wilt...

Ben ik het niet helemaal mee eens. Ik had tenminste kunnen zeggen: "Analyseer even heel goed naar wat de uitkomst is van die echo"
Dat had hem veel beter op weg geholpen.

Ik begeleid veel stagiaires en dan word ik wel eens moe om die zin steeds maar weer te herhalen.
De vraag die zij immers stellen is ook "het doe het niet".
Tja, wat zeg je dan?
1. ja ik zie het
2. wat is de error dan?
3. goh, wat erg. heb je vast een foutje gemaakt
4. wat staat er in de handleiding?
5. ......

Wat ik wel vind is dat programmeren een analytisch vak is, als je niet onderzoekend bent kom je niet verder in dit vak. Het kost tijd, en men vind tegenwoordig dat die tijd aan andere dingen besteed moet worden.

[ Voor 10% gewijzigd door DJMaze op 20-11-2015 10:02 ]

[MrDummy]

Meestal kun je debuggen, maar als de probleem heel klein is, dus één teken verschil, duurt het ook lang om goed na te lopen of in de juiste richting zoeken.
Als je al hele tijd programmeert en nu pas voor het eerst met punt probleem te maken heeft, heb je die kennis toen nog niet.

Door gebrek aan kennis zie je klein probleem nog niet. Je blijft dan verbaasd kijken. De echo heb ik al hele tijd voor de ogen, want ik heb ook resultaat afdruk onderaan in de script gedaan. Maar door de lange link lijkt alles goed eruit te zien. Nét niet genoeg alles gekeken.

Eigenlijk zou je bij gebrek aan kennis dit moeten doen: ook al weet je het niet, loop in dat geval teken voor teken na in de naam en vergelijk die met ervoor. Zie je het verschil?
De fout bij mij is bijna geheel rechts, maar ik kijk naar hele link (beetje in midden) en door diverse pogingen verandert link zelfs (met absolute link). Maar tot nu toe op Google is er geen hint verschenen (ik lees alle reacties door)

De waarschuwingen met dot in de naam komt niet overal voor, en zelden met $_POST + unlink.
Wel heb ik gekeken naar BigDump, maar ook hier komt niet direct naar voren omdat ik apart vond dat $_REQUEST direct gelezen kan worden.

Op internet kom ik verhalen tegen van mensen die niet wisten. Problemen met unlink heb ik nagetrokken, alles klopt. Maar zoeken op unlink problemen kom ik geen problemen tegen over $_POST naam en punt. Die is er vrijwel niet. Dat wordt weinig toegepast.

Als ik variabele namen maak, doe ik altijd zonder punt. Omdat iedereen dat doet.

Ik zeg dus hier: met gebrek aan kleine details kennis zoek je nog vertwijfeld rond. Pas als er iemand zegt: "er mag geen dot in $_POST naam zitten", dan kan ik in die richting zoeken en kan ik via de juiste zoekwoorden in Google de waarschuwingen over dot lezen. Dan zou ik naar de resultaat link kijken, waar het probleem zal aantonen: underscore ipv dot.

Eigenlijk zou je vanzelf leren bij lesboeken welke regels er zijn bij variabele naam maken, waarbij het gebruik van dots niet mag. Ik heb echter alles zelf uitgezocht zodat niet alles in mijn hoofd komt.

Ik was een uur lang aan het prutsen en zie het nog niet het probleem. Best lastig bij gebrek aan kennis. Zeker als je niet verwacht dat dots niet mogen, omdat het mooi ingesloten is tussen " ".

Programmeren kan normaal iedereen als je kennis hebt, schematisch doet en aan de opbouwregels houdt.
Elke keer dat ik heb gemaakt, test ik even tussendoor, zodat ik weet dat het werkt, en hoef ik niet nog es naar zoeken als het toch misgaat.

Een dokter weet heel veel, maar ziet ook niet altijd alles. Zeker niet als dokter nét die kennis niet heeft. (ik heb dit eens meegemaakt)

[RobIII]

MrDummy schreef op vrijdag 20 november 2015 @ 18:02:
Meestal kun je debuggen, maar als de probleem heel klein is, dus één teken verschil, duurt het ook lang om goed na te lopen of in de juiste richting zoeken.

Onzin. Eerst bekijk je de output. En, shit happens nou eenmaal, je ziet dat éne teken nou net over het hoofd en je vraagt je dus af waarom die file niet gewist wordt. Dan doe je eens een echo file_exists($fullfile); en die geeft vervolgens óók aan dat de file niet bestaat. Dus unlink én file_exists hebben allebei al een probleem met je file. Je zou nog wat minuten kunnen verspillen in 't zoeken in de richting van permissions maar na hooguit een paar minuten zou je toch écht tot de conclusie moeten komen dat er dus klaarblijkelijk iets niet goed zit in $fullfile. Er zou zelfs een onzichtbaar teken (tab, backspace, bell, whatever) in kunnen zitten of je ziet een 0 voor een O aan of x, ×, X, ✕, ☓, ✖, ✗, ✘ voor een X om maar eens wat te noemen. Dus de volgende stap die je neemt is iets als:

PHP:

echo strcmp($fullfile, 'deze-string-heb-ik-zélf-getypt-en-weet-ik-van-dat-hij-goed-is!')

Vervolgens zal óók strcmp je vertellen dat $fullfile niet is wat je verwacht en zo blijf je steeds terugcirclen naar die $fullfile. En als het kwartje dan nog niet gevallen is dan doe je iets als:

PHP:

$expected = '/var/www/foo/bar/baz.ini';

echo $fullfile;
echo $expected;

/var/www/foo/bar/baz_ini
/var/www/foo/bar/baz.ini

In de zeldzame gevallen die dan nog overblijven waardoor je 't verschil nog stééds niet ziet (door of lange strings of rare unicode tekens die niet van andere tekens te onderscheiden zijn of...) doe je een hex-dump (3 sec. googlen) van de string:

PHP:

echo bin2hex($fullfile);
echo bin2hex($expected);

2f7661722f7777772f666f6f2f6261722f62617a5f696e69
2f7661722f7777772f666f6f2f6261722f62617a2e696e69

...of je echo'd de hashes van beide strings (die dan afwijken en dus een verschil aangeven):

PHP:

echo sha1($fullfile);
echo sha1($expected);

f6d3013862e13e64ea7a8b44306629f9700c6878
0ac01bcfa1c9aed3d97d145457cb21dd7660dcdb

(maar minder handig omdat je niet ziet wáár het verschil zit, alleen dát er een verschil is).

En met een beetje creatief zoeken (als je 't verschil nóg niet ziet ) kom je nog meer mogelijkheden tegen:

PHP:

$expected = '/var/www/foo/bar/baz.ini';

$pos = strspn($fullfile ^ $expected , "\0");

printf(
    'First difference at position %d: "%s" vs "%s"',
    $pos, $fullfile [$pos], $expected [$pos]
);

First difference at position 20: "_" vs "."

Debuggen is methodisch te werk gaan. Stuk voor stuk zaken uitsluiten, (potentiële) problemen uitsluiten. Of juist omgekeerd: stapje-voor-stapje (babysteps!) verifiëren dat alles is wat je denkt dat het is / zou moeten zijn. Debuggen is niet "oh dat heb ik al eens eerder gezien en vanaf nu weet ik wat 't probleem is"; dan zou je nooit hoeven debuggen Dat je soms even moet doorbijten, verder kijken dan je neus lang is en jezelf overtuigen dat 't toch écht niet goed is is een tweede

Debuggen: Hoe doe ik dat?

[MrDummy]

Je hebt helemaal gelijk over vergelijken resultaten. Ik zou dat eigenlijk moeten doen.
Maar ik zeg maar even: net plank misgeslagen.
En ik heb niet altijd trek om uur lang te prutsen want daar word ik best wel moe van.

Nu ik het weet, zal ik alles goed en grondig doorlopen en ook goed vergelijken.
De tools zijn er inderdaad genoeg, resultaten vergelijken zou ik inderdaad moeten doen met compare scripts, dan ziet script het wel terwijl ik niet direct kan zien....

Inmiddels heb ik script van BigDump allang gepakt en daar verder uitgewerkt totdat het voldoet aan mijn wensen. Het voldoet al behoorlijk aan mijn wensen.

Waarom ik nog niet door heb: ik ben niet ervaren linux gebruiker en ik weet ook beetje dat linux filesysteem ook paar problemen kent waardoor file niet gewist kan worden i.v.m. rechten (user rechten) en chmod 0777. Dat zorgt voor de afleiding waar ik moet zoeken naar het probleem. De afleiding door andere mogelijke problemen in linux. Maar dat is achteraf natuurlijk niet zo.
Ik heb eerder schrijfproblemen gehad, maar daar kan ik wel achterkomen en oplossen met juiste chmod in directory.

Iedereen alsnog heel hartelijk bedankt. RobIII ook veel dank voor je post, het is heel uitgebreid.

[ Voor 29% gewijzigd door MrDummy op 20-11-2015 19:57 ]

[RobIII]

MrDummy schreef op vrijdag 20 november 2015 @ 19:47:
Waarom ik nog niet door heb: ik ben niet ervaren linux gebruiker en ik weet ook beetje dat linux filesysteem ook paar problemen kent waardoor file niet gewist kan worden i.v.m. rechten (user rechten) en chmod 0777. Dat zorgt voor de afleiding waar ik moet zoeken naar het probleem. De afleiding door andere mogelijke problemen in linux. Maar dat is achteraf natuurlijk niet zo.
Ik heb eerder schrijfproblemen gehad, maar daar kan ik wel achterkomen en oplossen met juiste chmod in directory.

Dat zijn nou juist dingen die je in no-time uitgesloten hebt omdat ze a) een fout veroorzaken (error_reporting aanzetten!) of b) in je logging verschijnen. En bovenstaand proces dat ik (min-of-meer) zou hebben doorlopen duurt echt geen uur/uren maar is een matter of minutes. Je moet alleen effe doorpakken en dus niet te snel opgeven of je schouders ophalen

[DJMaze]

MrDummy schreef op vrijdag 20 november 2015 @ 19:47:
Waarom ik nog niet door heb: ik ben niet ervaren linux gebruiker en ik weet ook beetje dat linux filesysteem ook paar problemen kent waardoor file niet gewist kan worden i.v.m. rechten (user rechten) en chmod 0777.

Dan was de error: Permission denied
En nu is de error: No such file or directory

Je kan je onkunde op het gebied van GNU/Linux niet de schuld geven, zet dat dus dan ook niet in je tekst.

"No such file or directory" zegt immers al alles wat je moet weten.

[Freeaqingme]

MrDummy schreef op vrijdag 20 november 2015 @ 19:47:
En ik heb niet altijd trek om uur lang te prutsen want daar word ik best wel moe van.

Dan moet je lekker gaan vissen, of postzegels plakken ofzo. Onderdeel van programmeren is nou eenmaal het oplossen bugs. Soms is het evident waar je bug ongeveer zal zitten (zoals hier het geval was). Soms, als je bijvoorbeeld meerdere threads hebt en een race conditie welke je nog niet hebt kunnen reproduceren dan kan het gebeuren dat je dagen bezig bent om methodisch het probleem te debuggen.

Het uren "prutsen" met een simpele bug als deze helpen je nou net dat methodisch denken en debuggen onder de knie te krijgen, zodat ook als je wat complexere code hebt je het kan oplossen. Nu _kan_ je het nog aan iemand anders vragen omdat het maar om een paar regels code gaat. Als je die onverklaarbare raceconditie moet vinden in duizenden regels code kan dat ook, maar dan zal je daar wel diep voor in de buidel moeten tasten...

[MrDummy]

Freeaqingme schreef op zaterdag 21 november 2015 @ 21:41:
[...]
Het uren "prutsen" met een simpele bug als deze helpen je nou net dat methodisch denken en debuggen onder de knie te krijgen, zodat ook als je wat complexere code hebt je het kan oplossen. Nu _kan_ je het nog aan iemand anders vragen omdat het maar om een paar regels code gaat.

Debuggen en opzoeken kan ik gelukkig voor groot deel wel doen. Alleen de regel van geen punten in naam $_POST was ik niet volledig op de hoogte. En dat zorgt voor een ongemak en verwarring, prutsen en niet in de juiste richting kijken. Dat klinkt misschien wel beetje dom.

Ik heb nu wel wat geleerd en zal dan ook opletten. Ik neem alle adviezen op, dus ik bedank iedereen hiervoor.