|
| HOMEPAGE | INDICE FORUM | REGOLAMENTO | ::. | NEI PREFERITI | .:: | RSS Forum | RSS News | NEWS web | NEWS software | |
| PUBBLICITA' | | | ARTICOLI | WIN XP | VISTA | WIN 7 | REGISTRI | SOFTWARE | MANUALI | RECENSIONI | LINUX | HUMOR | HARDWARE | DOWNLOAD | | | CERCA nel FORUM » | |
22-02-2010, 08.48.42 | #16 | |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
Quota:
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. |
|
22-02-2010, 09.29.43 | #17 |
Gold Member
Top Poster
Registrato: 07-04-2000
Loc.: Padova-Vicenza
Messaggi: 4.814
|
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.
___________________________________
Con il PC risolvo molti problemi che prima non avevo. - Coltiva Linux che Windows si pianta da solo! |
22-02-2010, 10.35.02 | #18 |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
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 |
22-02-2010, 11.05.17 | #19 |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
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$. |
22-02-2010, 13.42.45 | #20 |
Gold Member
Top Poster
Registrato: 07-04-2000
Loc.: Padova-Vicenza
Messaggi: 4.814
|
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.
___________________________________
Con il PC risolvo molti problemi che prima non avevo. - Coltiva Linux che Windows si pianta da solo! |
22-02-2010, 21.19.47 | #21 |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
Giustissimo Sergio (Y), ogni intervento può essere motivo di approfondimento.
|
22-02-2010, 22.17.27 | #22 |
Gold Member
Top Poster
Registrato: 07-04-2000
Loc.: Padova-Vicenza
Messaggi: 4.814
|
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.
___________________________________
Con il PC risolvo molti problemi che prima non avevo. - Coltiva Linux che Windows si pianta da solo! |
23-02-2010, 13.26.34 | #23 | ||
Gold Member
Registrato: 20-05-2004
Loc.: Perugia
Messaggi: 4.188
|
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. Quota:
Quota:
___________________________________
Ogni computer ha la sua storia. Dermatite Seborroica? www.dermatiteseborroica.info Ultima modifica di RunDLL : 23-02-2010 alle ore 13.31.26 |
||
23-02-2010, 14.37.00 | #24 | |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
Quota:
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. Ultima modifica di LoryOne : 23-02-2010 alle ore 14.48.42 |
|
23-02-2010, 22.19.57 | #25 |
Gold Member
Registrato: 20-05-2004
Loc.: Perugia
Messaggi: 4.188
|
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.
___________________________________
Ogni computer ha la sua storia. Dermatite Seborroica? www.dermatiteseborroica.info |
23-02-2010, 22.31.19 | #26 |
Gold Member
WT Expert
Registrato: 09-01-2002
Loc.: None of your business
Messaggi: 5.505
|
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. Ultima modifica di LoryOne : 23-02-2010 alle ore 22.38.18 |
23-02-2010, 22.50.36 | #27 |
Gold Member
Registrato: 20-05-2004
Loc.: Perugia
Messaggi: 4.188
|
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.
___________________________________
Ogni computer ha la sua storia. Dermatite Seborroica? www.dermatiteseborroica.info Ultima modifica di RunDLL : 24-02-2010 alle ore 20.55.59 |
23-02-2010, 23.34.06 | #28 |
Gold Member
Top Poster
Registrato: 07-04-2000
Loc.: Padova-Vicenza
Messaggi: 4.814
|
NASfiga...
___________________________________
Con il PC risolvo molti problemi che prima non avevo. - Coltiva Linux che Windows si pianta da solo! |
Utenti attualmente attivi che stanno leggendo questa discussione: 1 (0 utenti e 1 ospiti) | |
Strumenti discussione | |
|
|
Discussioni simili | ||||
Discussione | Autore discussione | Forum | Risposte | Ultimo messaggio |
Comportamento strano pendrive | fedele | Hardware e Overclock | 5 | 07-03-2006 01.25.46 |
programma di posta strano | Didy | Software applicativo | 7 | 22-07-2004 18.27.39 |
barra delle applicazioni - strano comportamento | SiN4pSi77 | Windows 7/Vista/XP/ 2003 | 4 | 18-07-2004 08.43.56 |
esiste un programma così? | ZeroOne | Software applicativo | 3 | 27-10-2003 23.15.40 |
comportamento strano | Giaccol | Windows 7/Vista/XP/ 2003 | 8 | 25-08-2003 15.29.17 |