Dostęp destroktora do unset() Opcje

[Athlan]

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:

Fatal error: Exception thrown without a stack frame in Unknown on line 0

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

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 (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif) może usunę to z mojej klasy (IMG:http://forum.php.pl/style_emoticons/default/tongue.gif)

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 (IMG:http://forum.php.pl/style_emoticons/default/smile.gif)

Ten post edytował Athlan 14.11.2006, 18:44:41

[Athlan]

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.

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:

Kod

constructor said: ./file.txt
destructor said: ./file.txt
destructor: no usable file

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?