Olimpo Informatico

[ZioCrick]

Buongiorno a tutti.

Sto facendo un programma Java in cui vengono copiati dei file dal disco fisso ad altri dischi USB o NAS.

Ho una stringa che contiene il percorso completo di un file, per esempio:
String sFile = "/media/Dati/Cartella/File.txt";
se faccio:
java.io.File fiName = new File(sFile);
la fiName.getPath() restituisce il percoso completo corretto.

Se invece la sFile contiene il percorso verso un NAS, esempio: "smb://nas1/public/Cartella/File.txt"
la fiName.getPath() restituisce "smb:/nas1/public/Cartella/File.txt"
ovvero mi toglie il secondo "/" dopo "smb:"

Questo fa si che le opertazioni con fiName, tipo una Files.copy non vanno a buon fine, perchè fiName non punta al NAS ma ad una cartella locale del disco in cui c'è l'ambiente di sviluppo.

Qualcuno sa darmi una mano su come risolvere?

[SverX]

ma la Files.copy supporta path di rete?

[ZioCrick]

Scusa il ritardo nel rispondere, ma in questi giorni sto impazzendo su questo problema.

In effetti ho scoperto che il Files non gestisce i pat della rete.

E mi hanno suggerito di aggiungere la libreira smbj-0.13.0.jar con tutte le sue dipendenze.
L'ho fatto ma ora sto litigando con un esempio che ho trovato in rete perché prima non mi vedeva il NAS con l'indirizzo: smb://nas1
Allora ho scoperto che me lo vede solo se uso l'indirizzo IP.

Ma adesso non fa ciò che è richiesto.
L'esempio è questo:

[SverX]

sembra che stampi una warning riguardo SLF4J e poi in effetti ti mostra . e .. che sono probabilmente il contenuto della directory vuota, quindi sembra funzionare - devi solo fare come spiega qui: https://www.slf4j.org/codes.html#noProviders

[ZioCrick]

Si, in effetti ho capito che è solo un warning che non blocca l'esecuzione.
Sono poi riuscito a creare la parte di programma per gestire le copie sui NAS, ma ora ho un altro problema.
Quando gestisco pochi file va bene, ma quando nelle cartelle da copiare ci sono migliaia di files diventa di una lentezza esasperante perché per ogni file da copiare deve fare la scansione di tutti i file già presenti nella cartella di destinazione per trovare se il singolo file esiste già e se la sua data di ultima modifica è più vecchia della versione da copiare dal disco del pc.
In pratica diventa lento come se dovessi copiare tutti i file presenti.
Allora sto cercando di inventarmi un algoritmo che non abbia bisogno di eseguire la scansione di tutti i file migliaia di volte.

Questo perché la libreria smbj non ha un metodo per verificare direttamente se un certo file esiste nella cartella di destinazione.

Se qualcuno avesse da suggerire un libreria più efficiente, ben venga.

[SverX]

il problema è solo quando la cartella di destinazione contiene già tanti file?

[ZioCrick]

Si perché per ognuno di essi l'algoritmo iniziale che fa uso della DiskShare e FileIdBothDirectoryInformation deve scandire tutte le migliaia di file nella cartella di destinazione per ognuno delle migliaia di file nella cartella di origine.

Poi in realtà ho modificato l'algoritmo in modo da fare il contrario, ovvero scandendo l'elenco dei file di destinazione e confrontandoli con la cartella di origine.
Così è molto più veloce, ma sto incontrando un altro problema in cui sembra che Java sbagli a fare il confronto tra due variabili long che contengono il valore in millisecondi delle date di ultimo aggiornamento del file di origine e destinazione.

Sto impazzendo, quindi se ci fosse un'altra libreria da utilizzare, diversa dalla smbj magari potrebbe risolvere il tutto.

[SverX]

ah, stai già facendo quello che pensavo di consigliarti.

per l'altro problema... difficile che un confronto tra due variabili numeriche fallisca, è possibile che in qualche modo non stai confrontando la data di ultima modifica ma qualche altra data?

[ZioCrick]

Hai perfetamente ragione!
Infatti ho scoperto che l'ordine con cui le due librerie scandiscono i file di una cartella è differente, per cui i test sulle date di modifica confrontavano due file differenti, per cui ho modificato completamente l'algoritmo di confronto e ora funziona perfettamente!

Ci sono ancora dei casi particolari in cui alcuni file che vengono sovrascritti perché con data più vecchia, in realtà la data di ultima modifica non viene aggiornata e quindi vengono sempre sovrascritti, ma questo credo che dipenda da particolarità del sistema operativo (Debian nel mio caso), e poi ci sono differenze di qualche decina di millisecondi anche per file che da sistema operativo risultano avere la stessa data di modifica.
Per ricolvere questo eseguo il confronto delle date con uno scarto di 1 secondo e tutto torna.
Grazie mille per la tua disponibilità.

[SverX]

c'è anche da considerare il problema che file system differenti hanno differenti risoluzioni per le date: FAT per esempio ha solo una precisione di 2 secondi quindi potrebbe non avere lo stesso valore del medesimo file salvato su EXT4 nello stesso identico momento...

[ZioCrick]

Si è vero, nel mio caso i dischi dati che uso come origine da copiare sono in ntfs, mentre i dischi USB e NAS non lo so.

Però ho gridato vittoria troppo presto!
Funziona tutto sui dischi collegati in USB e sui NAS, ma oggi ho provato ad eseguire il backup su un altro pc e sul portatile e..
le copie di file nuovi o la sovrascrittura di file vecchi funziona, compresa la ricorsione delle sotto directory ma...
quando deve cancellare un file o una cartella lo fa ma poi sta un po ad aspettare e mi da l'errore:

Exception in thread "AWT-EventQueue-0" com.hierynomus.smbj.common.SMBRuntimeException: com.hierynomus.protocol.transport.TransportException: java.util.concurrent.ExecutionException: com.hierynomus.smbj.common.SMBRuntimeException: com.hierynomus.protocol.transport.TransportException: java.io.EOFException: EOF while reading packet

Sul web ho trovato che può dipendere dall'impostazione del timeout, o da incorretta configurazione di Samba o differenti versioni tra client e server, ma allora mi chiedo: come mai le copie le fa e siccome i file di certe cartelle sono tanti, la connessione dura anche parecchio, per cui non mi capacito.

Qualche dritta?

[SverX]

ma la cancellazione avviene?

onestamente non ne ho idea, a intuito direi un bug nella libreria...

[ZioCrick]

Si, il file lo cancella, e se deve cancellare una directory me la svuota dei file contenuti ma poi non cancella la directory stessa.
Boh?

[SverX]

OK il fallimento della cancellazione della directory potrebbe essere un problema di permessi - però la libreria, se è fatta bene, dovrebbe rilevare e restituire un errore, non andare in crash...

[ZioCrick]

In effetti avevo pensato anch'io ai permessi, e verificando sono impostati esattamente nello stesso modo dei NAS.
Forse mi sono spiegato male, non è che il programma va in crash.
Semplicemente segnala l'errore e non prosegue l'esecuzione, ma il programma rimane in esecuzione.
Di fatto è come se andasse in crash perché non prosegue con la copia degli altri file.

Sono nella confusione più totale.