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

[mariuszn3]

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

Ten post edytował mariuszn3 19.11.2006, 17:50:29