PHP && Permissions, ...czyli chmod'y w PHPie Opcje

[Skie]

Witam,
natrafiłem na dość dziwny błąd, z którym nie mogę sobie poradzić.
Otóż w ostatnim czasie jednemu z użytkowników serwisu wyskoczył taki błąd podczas przeglądania podstron.

Kod

Warning: fopen(./includes/data/equipment/to_add/239.txt) [function.fopen]: failed to open stream: Permission denied in [xxx]/equipment.php on line 682

Są 2 wyjścia czemu taki błąd się pojawił - najczęstszy jest taki, że plik nie istnieje, lecz kod w tym fragmencie wygląda tak:

[PHP] pobierz, plaintext 
    $filePath = './includes/data/equipment/to_add/'.$player -> id.'.txt';
    if (file_exists($filePath) && ($filesize = filesize($filePath)) > 0) {
      $file = fopen($filePath, 'a+');
      $json = fread($file, $filesize);
      $json = json_decode($json, true);
      $countJSON = count($json);
      fclose($file);
 
      // [...]
   }  
[PHP] pobierz, plaintext 

Skoro if się wykonał znaczy że plik istniał, gdyż przeszedł przez file_exists();

Pozostaje więc 2 wyjście - nieodpowiednie uprawnienia plików - ale dlaczego?
Pliki w tym folderze są nadzorowane przez PHPa - sam je tworzy, edytuje, odczytuje etc. Folder w którym znajdują się te pliki ma uprawnienia 777.
Ponadto jest tam tych plików dużo dużo więcej i błąd pojawił się dotychczas jedynie 2 razy - co by znaczyło że 2 razy zawiodły uprawnienia?

Przy 1 wyjściu jest jeszcze ekstremalna teoria, że 2 skrypty zostały odpalone przez tego samego użytkownika tak ekstremalnie blisko siebie, że mogły same sobie zazgrzytać - ale to jest raczej niemożliwe.

Co może być powodem takiego dziwnego zachowania skryptu?

Z góry dziękuję za odpowiedź.

Ten post edytował Skie 11.08.2010, 11:48:16

[Pilsener]

239.txt

- co to jest za plik i skąd się bierze? Jeśli jest tworzony "w locie" przez PHP to możemy mieć problemy na niektórych serwerach! By tego uniknąć zalecam najpierw tworzenie pustego pliku przez touch, a nie fopen.

Potem sprawdzam:
- czy plik istnieje
- czy jest is_readable/is_writable etc.
- czy można go otworzyć

Przy plikach warto też robić kopie (a najlepiej trzymać je w bazie, by zawsze móc przywrócić w razie potrzeby), często plik np. cfg jest odtwarzany a klient nawet tego nie zauważa (IMG:style_emoticons/default/smile.gif) Zawartość pliku bywa często tracona przy próbie jego edycji, warto też mieć jakąś procedurę awaryjną na wypadek uszkodzenia pliku, jest plik 239.txt, który zawiera jakieś znaki i nie można nic z nim zrobić - gdy nie udaje się go usunąć/przywrócić leci mail do admina, by zrobił to przez ftp lub w bashu (IMG:style_emoticons/default/smile.gif)

skrypty zostały odpalone przez tego samego użytkownika tak ekstremalnie blisko siebie, że mogły same sobie zazgrzytać

- i tak i nie. Jeśli ktoś zapisuje plik to jest on blokowany na czas zapisu (przynajmniej tak powinno być), oczywiście blokowanie nie powinno dotykać w żaden sposób userów, którzy tylko odczytują plik, ale moze akurat tu jest inaczej?

Kiedyś pracowałem dużo z plikami i nauczyłem się, że plikom nie należy ufać i co jakiś czas któryś wypada z szeregu a już makabra gdy przychodzi pracować z plikami pod obciążeniem (równoczesny insert i update) lub na kiepskiem hostingu (częste pady i zrywanie łącza)