|
|
inviato il 04 Aprile 2026 ore 18:56
Vi rimando al sito offgallery.app per prendere visione dei due ultimi plugin creati.
Con l'occasione, un augurio a tutti di serena Pasqua!  |
|
|
inviato il 04 Aprile 2026 ore 19:36
 Auguri anche a te. |
|
|
inviato il 06 Aprile 2026 ore 17:03
Sto provando ad utilizzare OffGallery con un catalogo Lightroom ma purtroppo non individua le foto, le vede ma dice che non sono presenti.
Questo nel log:
[16:59:44] INFO - catalog_readers.lightroom_reader - Catalogo 'catalogo-test': 1813 file totali letti
[16:59:45] INFO - catalog_readers.lightroom_reader - Formati supportati: 1813 | Trovati su disco: 0 | Mancanti: 1813
Il catalogo è sul disco interno del mac, i file sono sul disco esterno (ed è collegato).
Altri hanno lo stesso problema? |
|
|
inviato il 06 Aprile 2026 ore 18:18
Ciao. No nessuno, mi pare però che proprio su Mac qualcuno l’ha privato. Io l’ho sperimentato sul mio pc windows con catalogo su disco interno e foto su disco esterno usb. Potrebbero esserci problemi con la nomenclatura mac dei file? Controllo stanotte. Grazie |
|
|
inviato il 06 Aprile 2026 ore 21:51
@Angrod @Michele_m
Oltre alla differenza tra Mac Silicon ed Intel si deve tener presente di:
File System del Disco Esterno:
Se il disco non è formattato correttamente per l'ambiente in cui gira il software (es. un disco NTFS su Mac usato senza driver di scrittura o con permessi non mappati, o un ExFAT che non gestisce i permessi proprietari), il sistema operativo nega l'accesso profondo ai file al processo Python, anche se il volume appare montato.
Permessi TCC (Volume):
Su macOS, se l'interprete Python o il Terminale non hanno l'Accesso completo al disco nelle Impostazioni di Sicurezza, il sistema 'vede' la cartella /Volumes/ ma ne blocca la lettura del contenuto reale.
File AppleDouble (._):
Durante la scansione, il Mac genera file invisibili ._ (metadati). Se il lettore del catalogo conta questi 'fantasmi' come immagini, il database si riempie di record vuoti che risulteranno sempre 'mancanti' perché non sono file grafici apribili. (Non so se è presente un controllo che non fa leggere i File ._ )
E questo punto mi sembra il tuo problema perchè ha visto 1813 file totali letti, ma poi dice che non ci sono formati supportati
Per questo motivo usavo Docker per isolare l'architettura Mac. |
|
|
inviato il 07 Aprile 2026 ore 0:52
Ciao Ivo, grazie per le osservazioni, sono tutte considerazioni sensate
Nel nostro caso però, il log è abbastanza indicativo: il catalogo legge correttamente 1813 file, tutti con estensione supportata, ma poi risultano 0 trovati su disco. Questo significa che il filtro formati sta funzionando e che il problema non è legato ai file AppleDouble (che Lightroom non registra nel catalogo), né all’architettura Intel/Silicon.
A quanto ho appurato, anche filesystem (NTFS, ExFAT, ecc.) o TCC in genere non portano a “exists() = False” su tutti i file in blocco: darebbero errori di permesso o problemi specifici, non 1813 mancanti netti.
Il punto più probabile è la gestione dei path: Lightroom salva sempre i percorsi in formato POSIX con “/”. Nel mio codice c’era una conversione forzata verso “\” pensata per Windows, che su macOS rende il percorso letteralmente sbagliato, quindi Path.exists() restituisce sempre False.
Sto correggendo quella parte per usare i path così come sono nel catalogo (formato POSIX), che è la soluzione cross-platform corretta.
Grazie ancora per il confronto — è sempre utile fare 'sanity check' a più livelli , soprattutto perche' io il mac non ce l'ho! |
|
|
inviato il 07 Aprile 2026 ore 9:55
Stavo per dire che il problema ti si sarebbe presentato quindi anche su Linux, poi mi sono ricordato che Adobe non sviluppa un tubo per il pinguino! |
|
|
inviato il 07 Aprile 2026 ore 10:33
"@Michele_m la mia voleva essere una risposta più generica per @Angrod e poi per conoscenza anche a te perché so come stai affrontando il problema.
Da quello che mi pare di capire però il Mac ha una diversità anche sui permessi dovuti alla base Unix da cui proviene (così come Linux), mentre x86 è diverso. Il passaggio da \ a / potrebbe non bastare perché su sistemi Unix-based i volumi esterni non sono solo "percorsi", ma punti di montaggio che sottostanno a gerarchie di permessi POSIX molto rigide. Se il processo che fa girare il catalogo non ha l'autorizzazione esplicita del kernel (TCC su Mac), il comando Path.exists() restituirà sempre False anche se il percorso è scritto correttamente, perché per il sistema il contenuto di quel volume è "invisibile" per motivi di sicurezza. |
|
|
inviato il 07 Aprile 2026 ore 10:46
Questo problema però in ogni caso lo risolvi con il montaggio tramite altro utente idoneo o la variazione dei permessi stessi sul mountpoint e relative sottocartelle: risolvi fuori, a livello di sistema quindi, non è risolvibile con variazioni al codice del programma.
Al più, se era quello che intendevi, si può tentare di rilevare la problematica più correttamente come "permesso negato" anziché limitarsi alla dicitura "file mancante", sempre se è possibile (non credo lo sia con un semplice "exists()"); in caso sia possibile credo questo presupponga test aggiuntivi via codice da eseguire (vedendo se è un mount point, in prima battuta, ad esempio?). |
|
|
inviato il 07 Aprile 2026 ore 13:34
Alle 14 mi si sblocca l’oracolo ma io torno a casa la sera e vi darò l’arduo responso |
|
|
inviato il 07 Aprile 2026 ore 16:38
Ho provato a creare un catalogo di test con 10 immagini sul disco interno del mac ma la situazione non è cambiata. In privacy e sicurezza ho dato accesso completo al disco al terminale e all'eseguibile python, nessun miglioramento :(
Il percorso dove ho messo il catalogo di test è tutto senza spazi e caratteri strani, se provo dal terminale con un ls visualizzo correttamente i file. |
|
|
inviato il 07 Aprile 2026 ore 19:15
@Angrod
Il problema non è se c'è o no il file,
il problema è poter avere accesso a quel file.
Se non si hanno i permessi che MacOS ritiene sicuri è tutto rifiutato per sicurezza. |
|
|
inviato il 07 Aprile 2026 ore 19:45
Eccomi! L'Oracolo ha parlato x ANGROD!
il fix è stato pushato su origin/main nel commit ead65e6.
La causa era riga 107 di catalog_readers/lightroom_reader.py:
# PRIMA (rotto su macOS)
file_path = Path(raw_path.replace('/', '\\') if '\\' not in raw_path else raw_path)
# DOPO (corretto)
file_path = Path(raw_path)
Lightroom internamente usa sempre / come separatore. Il vecchio codice convertiva forzatamente in \ qualsiasi path che non conteneva già \
— su macOS tutti i path sono POSIX (/Volumes/DiskEsterno/...) quindi venivano tutti storpiati e exists() restituiva sempre False.
L'utente macOS deve solo aggiornare (git pull o scaricando l'ultima versione) e i 1813 file del suo catalogo verranno trovati correttamente.
Fammi sapere , vediamo se l'Oracolo ha detto il vero |
|
|
inviato il 07 Aprile 2026 ore 21:42
“ Fammi sapere , vediamo se l'Oracolo ha detto il vero MrGreen „
Funziona!!
Grazie! |
|
|
inviato il 08 Aprile 2026 ore 9:26
Quindi era solo accesso, non permesso... in effetti se la mount del disco esterno avviene sotto l'utente che lancia pure il task di OffGallery, un errore di permesso sarebbe stato strano e assai peculiare (benché non impossibile, visto il ginepraio di permessi dei sistemi Unix-like). |
Che cosa ne pensi di questo argomento?
Vuoi dire la tua? Per partecipare alla discussione iscriviti a JuzaPhoto, è semplice e gratuito!
Non solo: iscrivendoti potrai creare una tua pagina personale, pubblicare foto, ricevere commenti e sfruttare tutte le funzionalità di JuzaPhoto.
Con oltre 260000 iscritti, c'è spazio per tutti, dal principiante al professionista. |
Metti la tua pubblicità su JuzaPhoto (info) |
JuzaPhoto contiene link affiliati Amazon ed Ebay e riceve una commissione in caso di acquisto attraverso link affiliati.
