Bonjour à tous,

Je l’ai zappée, mais depuis le 28 octobre, votre app Creative Cloud vous propose une mise à jour 12.01 qui règle les bugs suivants :

• Problème de mise à jour d’un catalogue situé sur un disque externe (concerne macOS 13 Ventura).
• La sauvegarde de catalogue n’incluait pas le fichier .lrcat-data (il contient les masques de retouche locale et de l’outil Correcteur).
• Le filigrane de copyright n’est pas appliqué à l’export.
• Impossible de voir les infos système via le menu Aide (Windows).

En revanche, nouvelle version, nouveau bug : impossible de sauvegarder un catalogue sur un disque en réseau (et, donc, si c’est votre cas, faites vos sauvegardes sur un simple disque externe en attendant).

À bientôt !

Gilles.

Mise à jour 19h15 : article complété

Bonjour à tous,

Je reviens un instant sur les différentes polémiques, concernant les méthodes mises en avant par certains sites pour contourner l’interdiction de placer un catalogue Lightroom en réseau.

Adobe et, plus particulièrement, les développeurs de Lightroom déconseillent totalement d’utiliser un catalogue en réseau (que ce soit la simple installation qui va générer un message d’alerte, ou par l’intermédiaire d’images disques et de liens symboliques). De ce fait, j’ai donc été voir ce que raconte le site officiel SQLite, qui est le format de base de données employé par Lightroom. Et le moins qu’on puisse dire, c’est que la lecture, en dehors des passages techniques plutôt abscons, est forte en enseignements et surtout, sans aucune ambiguité à ce propos : la moindre faille qui se produit lors de l’écriture dans le catalogue peut entraîner une corruption de ce dernier, comme l’explique cette page :

« 6.0 How To Corrupt Your Database Files:

SQLite uses POSIX advisory locks to implement locking on Unix. On Windows it uses the LockFile(), LockFileEx(), and UnlockFile() system calls. SQLite assumes that these system calls all work as advertised. If that is not the case, then database corruption can result. One should note that POSIX advisory locking is known to be buggy or even unimplemented on many NFS implementations (including recent versions of Mac OS X) and that there are reports of locking problems for network filesystems under Windows. Your best defense is to not use SQLite for files on a network filesystem. »

Traduction :

« 6.0 Comment corrompre votre base de données :

SQLite utilise des verrous POSIX pour Unix. Sous Windows, il utilise les routines LockFile(), LockFileEx(), et UnlockFile(). Dans ce cas, SQLite suppose que ces routines de contrôle fonctionnent comme il se doit et, si ce n’est pas le cas, on se retrouve avec un risque de corruption de la base de données. POSIX est également connu pour ses propres problèmes techniques, sans parler de la possibilité qu’il ne soit pas utilisé sur les implémentations NFS (y compris les versions récentes de Mac OS X), et des problèmes de verrouillage de fichiers en réseau ont été signalés sous Windows. Dans ce cas, la meilleure protection est de ne pas utiliser de base de données SQLite en réseau. »

Ce n’est donc pas moi qui l’affirme mais bien le site du développeur SQLite sur cette page (section 6.0) !
Lire la suite de cet article »