Programma batch adotta uno strano comportamento

[LoryOne]

Inviato da LoryOne

potresti verificare con il comando dir \\...\....\abc*.xxx per visionare la lista dei files che vengono proposti e verificare che siano effettivamente quelli che ti aspetti.

Mi quoto perchè ho preso una cantonata. Mi spiego meglio:
DIR [unità:][percorso][nomefile]
Pertanto è impossibile utilizzare la sintassi dir \\...\ecc. non funzionerà mai.
E' necessario utilizzare net view \\...
Si può utilizzare il comando dir su percorsi di rete solo se si è mappata un'unità, così da essere in accordo con l'help.
Mi sa che dovresti rivedere il batch definendo meglio i drives mappati:
DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK
STORAGE non sarà mai raggiunto

ps: resta corretto il discorso dell'hidden pipe IPC$ sul target.

[Sergio Neddi]

Si, infatti avevo consigliato all'inizio di usare un'unità mappata, magari al volo con net use per evitare problemi, però in realtà alcuni comandi funzionano anche dichiarando il percorso UNC, per cui alla fine non resta che provare.
Vedremo come procede, sembra comunque che il problema sia stato risolto utilizzando nomi di file differenti.
Tenere presente anche che, se il NAS è basato su Linux ed il file system è NTFS come dichiarato da RunDLL, non è detto che venga gestito correttamente in quanto la gestione NTFS di Linux non è che sia un granché. Sarebbe stato più adatto un file system Linux. Ci potrebbero essere sorprese anche da questo lato.

[LoryOne]

In effetti Rundll ha modificato i nomi dei files riducendoli ad 8 caratteri estensione esclusa, però la cosa mi sembra inutile anche se sul NAS è presente Linux poichè:
1 - SMB è presente, infatti il NAS ha un server SAMBA
2 - La FAT sull hd è NTFS.
In queste condizioni la limitazione ad 8 caratteri sul nome file dovrebbe essere ampiamente superata.
Io sono convinto che debba mappare opportunamente il persorso sul NAS e che debba prestare attenzione al percorso racchiudendolo tra doppi apici solo se contiene spazi al suo interno. Diverso sarebbe il discorso se sul NAS fosse presente un filesystem Linux

[LoryOne]

Aggiungo anche, salvo smentite, che SAMBA resta in ascolto sulle classiche porte riservate ad SMB e riceve i pacchetti TCP/IP che contengono istruzioni in accordo con le specifiche CIFS. Il nome del file è presente nel flusso dati ed è Windows che lo specifica.
Linux deve accedere a NTFS per compiere le operazioni specificate sul nome del file così come gli è giunto da Windows attraverso SAMBA che non può non ricnoscere il nome del file. Linux, quindi, deve aver montato il device di memorizzazione riconoscendo NTFS, quindi è sicuramente in grado di gestire il file secondo le specifiche di archiviazione di M$.

[Sergio Neddi]

Si, si, in teoria... in realtà ci sono di quelle schifezze in giro sui dispositivi economici che non ci metterei la mano sul fuoco sul fatto che le cose vengano gestite correttamente. Ecco perché ho fatto le mie considerazioni.

[LoryOne]

Giustissimo Sergio (Y), ogni intervento può essere motivo di approfondimento.

[Sergio Neddi]

Faccio un esempio di sorprese capitate. Successo anni fa: un cliente ha delle macchine di taglio polistirolo che lavorano ancora in DOS. Utilizzano una procedura (a suo tempo sono impazzito a fare i necessari batch per i vari automatismi - originariamente lavorava con server Novell Netware) che consente di trasferire in locale i file delle sagome copiandoli da un server Linux. I file con nomi lunghi venivano troncati: normale, lavorando in DOS. Poco male per il cliente in quanto i nomi erano riconoscibili quanto basta.
Ma un bel giorno è stato sostituito il server con una versione di Linux più recente. In particolare era passato a samba 3.
Che è successo? Le macchine scaricavano i file, ma era un casino riconoscerli in quanto i nomi conservavano solo l'iniziale originale, ma i caratteri seguenti erano casuali, rendendo i file irriconoscibili.
In realtà, ho scoperto poi, c'è un'impostazione in questa versione di samba che consente di avere i nomi raccorciati secondo vari criteri, ma quello predefinito è di avere i nomi casuali.
Tra l'altro ho fatto una prova collegandomi a Linux via samba con XP: utilizzando vecchi programmi DOS che supportano solo i nomi corti lo stesso problema succede anche con XP, normalmente non ce ne accorgiamo in quanto ormai programmi che usano solo nomi corti non ce ne sono.
Tutto questo per dire che di sorprese, quando si fanno reti miste, ce ne sono.

[RunDLL]

Buongiorno a tutti! Allora nel backup del lunedì ho sostituito i nomi come avevo fatto nel batch domenica pomeriggio.
Pertanto "Lunedi.bck" è diventato "Lun.bck", "Lunedi_VM.bck" è diventato "Lun.bck" ed "Eichette.bck" è diventato "Etichett.bck". Pertanto ho ridotto i nomi a massimo 8 caratteri estensione esclusa e eliminato caratteri particolare come l'underscore.
Ieri ha copiato questi "benedetti" bck regolarmente (questo lo faceva anche prima ma poi li cancellava al successivo comando DEL) ma soprattutto il comando DEL non li ha cancellati, utilizzando il nome UNC nel percorso.
Vorrei però precisare che, ora io ho messo il listato solo della parte "incriminata" del batch ma prevede anche altri comandi tipo ROBOCOPY di alcune cartelle sempre da server verso il NAS.
Bhè questi comandi ROBOCOPY sono stati sempre eseguiti regolarmente copiando tutti in file anche se avevano nomi più o meno lunghi o con underscore.
È Proprio una stranezza.

Inviato da LoryOne

Io sono convinto che debba mappare opportunamente il persorso sul NAS e che debba prestare attenzione al percorso racchiudendolo tra doppi apici solo se contiene spazi al suo interno. Diverso sarebbe il discorso se sul NAS fosse presente un filesystem Linux

Avevo già provato, come suggerito da Sergio a mappare l'unità e/o a racchiudere il percorso tra apici ma non c'era stato risultato.

Inviato da Sergio Neddi

Si, si, in teoria... in realtà ci sono di quelle schifezze in giro sui dispositivi economici che non ci metterei la mano sul fuoco sul fatto che le cose vengano gestite correttamente. Ecco perché ho fatto le mie considerazioni.

Penso di trovarmi proprio di fronte a questo caso. Infatti non utilizzerò mai più prodotti Eminent, al di là di questo anche con altri oggetti ho avuto altri problemi dell'Eminent.

[LoryOne]

Inviato da RunDLL

Avevo già provato, come suggerito da Sergio a mappare l'unità e/o a racchiudere il percorso tra apici ma non c'era stato risultato.

Io intendevo dire che avrei proceduto ad eliminare tutti i percorsi UNC, persino quelli relativi al comando del. Il percorso tra apici non c'entra se non contiene spazi al suo interno. Devi fare attenzione alla FAT sulla quale leggi o scrivi. Se sul server e sul NAS esiste la stessa FAT, il nome del percorso deve essere mantenuto senza alcun intervento preventivo sul PC di destinazione. (da questo effettuato, SMB non verrebbe chiamato in causa)
Ora, se sei riuscito ad effettuare la copia attraverso due percorsi mappati rispettivamente sul server e sul NAS, allora è l'operazione di cancellazione che non è consentita sul NAS, poichè i percorsi in copia sono stati accettati: Perchè non dovrebbero esserlo con il comando ci cancellazione ?

Contrariamente, qualora la FAT sorgente accettasse i nomi lunghi (ad esempio FAT32/NTFS) e quella destinazione no (ad esempio FAT16) , la destinazione autonomamente procederebbe a troncare il nome secondo le specifiche di archiviazione in FAT. Potrebbe verificarsi il caso di omonimia, pertanto potresti trovarti nomi come pluton~1.xxx e pluton~2.xxx, ma sarebbero archiviati in posizioni distinte in base ad altri criteri.

[RunDLL]

L'hard disk da cui provengono i file del server è NTFS, allo steso modo è formattato l'hard disk del server, poi come venga interpretato dal sistema operativo del NAS non saprei.
Il discorso che fai sul troncamento nomi e quindi poteva trovarsi davanti ad un caso di omonimia può essere corretto e ci avevo pensato, ma fin tanto parliamo di giovedi e giovedi_vm, ma giovedi_vm e etichette non può rientrare nel caso di omonimia.
Però adesso che ci penso il disco l'ho formattato con l'utility del NAS che sinceramente non da a sapere il file system che utilizza.

[LoryOne]

Allora andiamo un po più a fondo:
Mi ritorna in mente il discorso di Sergio sul fatto che giovedi_vm e giovedi potessero essere inerpretati come lo stesso file.
Bene armati di sniffer sniffa la connessione su due files creati ad arte: Prima copia un file dal server verso il NAS e poi dal NAS verso il server. Sicuramente ruscirai ad identificare il nome del file: Cambia nei due sensi, oppure è sempre lo stesso ?
Cerca di capire quale possa essere la causa: Visto che TCP/IP è comune ad entrambi i S.O. e che il nome del file deve viaggiare tra i pacchetti scambiati, guarda da quale parte può essere mal interpretato. (se è mal interpetato). ricorda che SAMBA ha un suo file di configurazione al quale Sergio ha accennato pochi posts fa.

[RunDLL]

Il viaggio del file è a senso unico, ovvero il file viene copiato dal Server al Nas e non viceversa. È tanto per dire, ho capito che fare la copia a doppio senso è solo per fare una prova.
Ma c'è da dire che il file giovedi.bck viene copiato regolarmente nel nas e ci rimane se non che arriva il comando "del giovedi_vm.bck" che lo cancella, ma finchè non parte questo comando il file è copiato e rimane nel nas.
Stessa cosa per "giovedi_vm.bck" viene copiato nel nas e sta là finchè non arriva, dopo altri comandi, infatti prima del del ci sono altri comandi nel batch, finchè non arriva "del etichette.bck".
Cioè il file viene copiato nel nas indipendentemente dal suo nome o lunghezza è quando arriva il del che viene cancellato, se non ci fosse nessun del il file rimarrebbe copiato tranquillamente nel nas.
Avevo pensato anche io che giovedi e giovedi_vm potesse essere interpretato come giovedi o giov o giove, insomma che lo troncava e lo rendeva omonimo, ma come ho detto il discorso non fila tra "giovedi_vm" ed "etichette".
Cioè alla fine avrei anche risolto ma ero curioso di raccapezzarci qualcosa.

[Sergio Neddi]

NASfiga...