Verrouillage de fichier transactionnel

Le mécanisme de verrouillage de fichier transactionnel d’ownCloud verrouille les fichiers pour éviter la corruption de fichiers pendant les opérations normales. Il réalise les actions suivantes :

  • opération à un niveau supérieur à celui du système de fichiers, de sorte que vous n’avez pas à utiliser un système de fichiers gérant le verrouillage ;
  • verrouillage des répertoires parents de sorte qu’ils ne puissent être renommés pendant toute activité survenant sur des fichiers dans les répertoires ;
  • libération des verrous après interruption des transactions de fichiers, par exemple, quand un client de synchronisation perd la connexion pendant un téléversement ;
  • gestion correcte du verrouillage et de la libération de verrou des fichiers sur les fichiers partagés pendant les modifications effectuées par plusieurs utilisateurs ;
  • gestion correcte des verrous sur les montages de stockages externes.

Ce pour quoi n’est pas fait le verrouillage de fichier transactionnel : * empêcher les collisions lors de l’édition collaborative de documents (consulter Configuration de l’application collaborative Documents pour en apprendre plus sur la collaboration avec l’applications Documents) ; * empêcher les utilisateurs d’éditer le même document ou prévenir que d’autres utilisateurs travaillent sur le même document.

Plusieurs utilisateurs peuvent ouvrir et éditer un fichier en même temps sans que le verrouillage de fichier transactionnel puisse l’empêcher. Par contre, il empêche l’enregistrement simultané par plusieurs utiliateurs d’un fichier.

Note

Le verrouillage de fichier transactionnel fait partie du code de base d’ownCloud et remplace l’ancienne application File Locking. Cette application a été retirée d’ownCloud dans la version 8.2.1. Si votre serveur ownCloud a toujours cette application, vous devez vous rendre sur votre page Applications pour vérifier qu’elle est bien désactivée ; l’application File Locking et l’application de verrouillage de fichier transactionnel ne peuvent opérer en même temps.

Le verrouillage de fichiers est activé par défaut et utilise le mécanisme de verrouillage de la base de données. Ceci provoque une charge significative sur votre base de données. Utiliser memcache.locking retire cette charge de la base de données et améliore les performances. Les administrateurs de serveurs ownCloud fortement sollicités doivent utiliser un mécanisme de memcache (consulter Configuration de la mémoire cache.)

Pour utiliser un memcache avec le verrouillage de fichier transactionnel, vous devez installer le serveur Redis et le module PHP correspondant. Après avoir installé Redis, vous devez modifier votre fichier config.php comme dans cet exemple:

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array(
     'host' => 'localhost',
     'port' => 6379,
     'timeout' => 0.0,
     'password' => '', // Optional, if not defined no password will be used.
      ),

Note

Pour une sécurité renforcée, il est recommandé de configurer Redis avec un mot de passe. Consulter http://redis.io/topics/security pour plus d’informations.

Si vous voulez configurer Redis pour qu’il écoute un socket Unix (ce qui est recommandé si Redis est installé sur le même serveur qu’ownCloud), utilisez cet exemple de configuration de config.php:

'filelocking.enabled' => true,
'memcache.locking' => '\OC\Memcache\Redis',
'redis' => array(
     'host' => '/var/run/redis/redis.sock',
     'port' => 0,
     'timeout' => 0.0,
      ),

Consultez le fichier config.sample.php pour voir les exemples de configuration et pour tous les mécanismes de memcache gérés.

Si vous utilisez Ubuntu, vous pouvez suivre ce guide pour une installation complète à partir de zéro.

Vous pouvez en apprendre plus sur Redis sur le site Redis. Memcached, le système de cache mémoire distribué populaire, ne convient pas pour le nouveau verrouillage de fichiers car il n’est pas conçu pour stocker les verrous et les données peuvent disparaître du cache à tout moment. Redis est un magasin de clé-valeur, et garantit que les objets en cache sont disponibles aussi longtemps que nécessaire.

Pour les utilisateurs de Debian Jessie, veuillez consulter cette discussion Github si vous rencontrez des problèmes avec l’authentification LDAP.

Toute la documentation est sous licence Creative Commons Attribution 3.0 Unported license — Traduction : Cédric Corazza.