Realizując projekt przyszła mi potrzeba dopisania pewnej klasy do mojego frameworka. Mianowicie, ma ona przechwycić plik uploadowany z podanego pola i skopiować go do plików tymczasowych frameworka. Stamtąd może wyciągać informacje o nim. Po zuploadowaniu klasa może przyjąc plik w inne miejsce metodą publiczną copy(). Nie będę jednak opisywał działania klasy, ale przedstawię główne zadanie:

Skopiować plik do folderu plików tymczasowych framework ( /application/var/ ) przy konstruktorze i skasować go w destruktorze.

Ostatnio dość irytującą rzeczą stał się fakt, iż desruktor nie może użyć funkcji unlink() (usowania pliku). Gdy wypluję jego ścieżkę za pomocą echo(), wówczas zostanie ona wyświetlona, ba, mogę ją nawet usunąć z buforu funkcją unset(). Patrząc na te aspekty, można stwierdzić, że destruktor ma pełny dostęp do danych przed zniszczeniem instancji klasy. Ok, fajnie, pobierzmy sobie dla funkcji unlink() zmienną którą zwraca metoda $this->_temp() (ścieżka do pliku na którym pracuje sobie klasa. Po zakończeniu prac na pliku, trzeba go usunąć. Zamiast usunięcia pojawia się tajemniczy błąd:



Klasa wygląda mniej więcej tak:

[PHP] pobierz, plaintext 
<?php
 
final class Vfile
{
	// ...
 
	public function __destruct()
	{
		unlink($this->_temp());
	}
 
	// ...
}
 
?>
[PHP] pobierz, plaintext 

gdyby wstawić echo(), wypluje nam scieżkę do pliku, ale nie widocznie php nie chce użyć funkcji unlink() w destruktorze.

Coś pominąłem, źle robie? A może destruktor wywoływany jest później niż zamykane są prawa dostępu do pliku (chociaż nielogiczne)? Czy jest jakiś haczyk na mój problem?

btw: to samo mam z obsługą sesji na plikach tekstowych, z bazą danych działa

Problem rozwiązałem kopjując plik do /var/ mojego frameworka w konstruktorze, zbierając wszystkie informacje i usówając również w konstruktorze. Wszystkie metody zwracają poszczególne informacje... wobec tego destruktor pozostaje bezrobotny (i dobrze), gdyż nie musi usówac pliku, bo zostało to wykonane zaraz po wykonaniu kopii zapasowej przez framework z tempu serwera. Gdy metoda mojej klasy copy() zostanie poproszona o plik, ponownie skopjuje go z tempu serwera juz w docelowe miejsce. Myślę, że połowa z Was powie: "poi co framework kopiuje sobie plik do swojej własnej pamięci?". Szczeże mówiąc sam się zastanawiam może usunę to z mojej klasy

Ostatecznie jednak zdecydowałem się, że nie będę zasmiecał pamięci frameworka... a niech klasa sobie lata do tempu serwewa... Ostatecznie wygląda to tak

[PHP] pobierz, plaintext 
<?php
 
final class Vfile
{
	private $_sInstance = NULL;
	private $_aFilePost = array();
	private $_aFileData = array();
 
	public function __construct($sPostField)
	{
		if(!defined("V_VAR"))
			throw new VfileException('V_VAR has no defined!');
 
		$this->_sInstance = $sPostField;
		$this->_aFilePost = $_FILES[$sPostField];
 
		$this->_aFileData				=	$this->_aFilePost;
		$this->_aFileData['extension']	=	end(explode('.', $this->_aFileData['name']));
		$this->_aFileData['temp']		=	$this->_aFilePost['tmp_name'];
	}
 
	public static function posted($sPostField)
	{
		return (bool) (isset($_FILES[$sPostField]['tmp_name']));
	}
 
	public function copy($sFilePatch, $sFileName = NULL)
	{
		$sFileName = ($sFileName) ? $sFileName : $this->name;
 
		if(!($bResult = copy($this->temp, $sFilePatch . $sFileName)))
			throw new VfileException('I cannot load file "' . $sFileName . '" to directory "' . $sFilePatch . '"!');
 
		return $bResult;
	}
 
	public function __get($sInfoCardKey)
	{
		return (isset($this->_aFileData[$sInfoCardKey])) ? $this->_aFileData[$sInfoCardKey] : NULL;
	}
 
	public function info()
	{
		return $this->_aFileData;
	}
}
?>
[PHP] pobierz, plaintext 

Pozdrawiam, Athlan

W destruktorze już nie ma dostępu do właściwości (są usunięte) - to też zależy... każdemu co innego wychodzi. W php destruktory to najbardziej "niezrozumiałe" zjawisko.

No tak @hwao, mielismy okazję je omówić na komunikatorze co rozumiesz przez słowo "właściwości" ?

Jeżeli "właściwości" rozumiesz jako atrybuty, to owszem... destruktor ma do nich dostęp. Może na nich operowac itd. Zauwazyłem jednak, że destruktor ma pełne prawa do zapisu danych do bazy danych (zaużmy przy własnej obsłudze sesji) ale do praw plików nie ma wogóle dostępu. Gdy za bezę danych podstawiłem do zapisu file_put_contents() z zasetrializowaną tablicą sesji, wówczasz plik się tworzy... ale pusty, zupełnie jakby ładował do neigo NULL.

Sprawa ciekawa, czasem można powiedzieć - wkurzająca. Moim zdaniem destruktor powinien mieć pełne prawa do systemu plików, może napiszemy petycję do twórców php ?

W pierwszym przykładzie dosyć istotna jest jednak zawartość metody temp() jaki jest jej algorytm? Czy korzysta z innych obiektów? Ostatnio miałem problem z kolejnością wywoływania destruktorów zaaktualizowałem php (z 5.1 na 5.2) od razu problem zniknął - tak więc w pierwszej kolejności proponuję się upewnić, że masz ostatnią wersję php'a

Warto byłoby czytać posty dokładnie... pod skryptem jest napisane:


Jak widać destruktory nie mają dostepu do ystemu plików, wszystkie operacje trzeba przekazać konstrutorowi, tak też zrobiłem

Pozdrawiam

Sorry nie doczytałem dokładnie.
Tak czy siak nie jest prawdą, że destruct'ory nie mają dostępu do operacji na plikach, niby dlaczego tak miałoby być? Tak jest w specyfikacji? Czy twierdzisz tak, bo w Twojej aplikacji coś nie zadziałało?
Napisz najprostszy możliwy test wywołujący unlink() w destruct'orze i zobaczysz, że zadziała - coś innego u Ciebie nie gra.
Z której wersji php korzystasz? To może mieć kluczowe znaczenie.

Zazwyczaj jak mi coś nie działa tworzę testy. Specjalnie dla Ciebie zadedykowałem poniższy kod obrazujący mój pogląd, a raczej fakt istanienia błędu (jeżeli mogę tak to nazwać).

Używam php 5.2.0, pozwoliłem sobie stworzyć kod obrazujący moją teorię i okazało się, że mam rację:

[PHP] pobierz, plaintext 
<?php
 
/**
 * Test by Piotr 'Athlan' Pelczar
 * 
 * Klasa pokazuje jakie prawa dostępu do plików ma destruktor i konstruktor
 * 
 * NOTE:
 * 
 * specjalnie została użyta funkcja die() a nie wyjątek, gdyż
 * w destruktorze nie mogą być łapane żadne wyjątki... a przerwanie jego
 * pracy jest konieczne. Udowodnone jest to, że destruktor ma pełne prawa
 * do atrybutu $this->_sFilePatch.
 * 
 * ATTENTION:
 * 
 * przed odpaleniem klasy nalezy stworzyć plik i nadać mu
 * prawa chmod 777 o nazwie/ścieżce podanej w konstruktorze klasy.
 * 
 */
 
// budujemy klasę...
class MyTest
{
	private $_sFilePatch = null;
 
	public function __construct($sFilePatch)
	{
		$this->_sFilePatch = $sFilePatch;
 
		echo 'constructor said: '.$this->_sFilePatch.'<br />';
 
		if(!file_exists($this->_sFilePatch) || !is_writable($this->_sFilePatch))
			die('constructor: no usable file');
	}
 
	public function __destruct()
	{
		echo 'destructor said: '.$this->_sFilePatch.'<br />';
 
		if(!file_exists($this->_sFilePatch) || !is_writable($this->_sFilePatch))
			die('destructor: no usable file');
 
		unlink($this->_sFilePatch);
	}
}
 
// ok odpalamy klasę...
$oMyTest = new MyTest('./file.txt');
 
?>
[PHP] pobierz, plaintext 

Otrzymałem nastepujący rezultat:



Jak widać... konstruktor w pełni widzi plik (ma do niego dostęp), a destruktor (pomimo tego że używa odpowieniego atrybutu) pliku nie widzi... paradoksalne zjawisko prawda?

Pierwsza sprawa - Twój test to nie jest idealnym wyizolowaniem problemu, u Ciebie może wejść w drogę parę innych bug'ów php (jeśli takowe są).. przez to nie możesz być pewien co naprawdę u Ciebie sprawia, że test daje wynik negatywny.
Myślę, że idealnym testem byłby następujący kod:

[PHP] pobierz, plaintext 
<?php
class MyTest {
 public function __destruct() {
	   unlink('/var/www/test');
	}
}
// ok odpalamy klasę...
$oMyTest = new MyTest();
?>
[PHP] pobierz, plaintext 

i nic poza tym (zwróć też uwagę na absolutną ścieżkę do pliku) jak to powyżej się wykrzaczy, możesz już z dużą pewnością przyjąć, że coś jest nie tak z dostępem do plików w destruktorze (ale warto to jeszcze potwierdzić na innym systemie z tą samą wersją php)

Odpalałem również Twój kod, zarówno pod windows'em i linux'em i wszystko działa tak jak powinno - plik jest kasowany..
Lecz kto wie, może faktycznie jest to bug php dopiero nie dawno naprawiony, bo zarówno pod windowsem jak i linuxem mam php (pobrane z dwa tygodnie temu) ze snapsów (wersja 5.2.1-dev).
Nie mam teraz możliwości sprawdzenia tego pod 5.2.0 Tak więc moja sugestia - pierw sprawdź czy brak absolutnej ścieżki do pliku nie ma na to wpływu, następnie albo zaktualizuj się do ostatniej dystrybucji dostępnej w snaps'ach lub jeśli nie masz takiej możliwości szukaj potwierdzenia swojej tezy na innym systemie z php 5.2.0

A więc podałem i absolutną ścieżke pliku i plik nie jest kasowany...

Co do mojego testu... dałem go "aż" taki "wieki" bo chciałem udowodnić, że konstruktor widzi plik, a destruktor nie... poza tym destruktor ma dostęp do atrybutu, który określa ścieżkę do pliku. W bugtrack było o tym dosyc głośno:

http://bugs.php.net/bug.php?id=32412 - bug z php4
http://bugs.php.net/bug.php?id=30267 - bug z php 5.0.1

Ciekawa sprawa... warto to potestować, dzięki Ci @mariuszn3 że się zainteresowałeś... czekam na inne odpowiedzi pozostałych uzytkowników forum. Zapewne mają coś do dodania

Pozdrawiam, Athlan

--[edit]--

Jeżeli znajdę chwilkę, podejme sie dokładniejszych oględzin problemu: zapizywanie, czytanie z plików itd.