PDA

Visualizza versione completa : Programma batch adotta uno strano comportamento


RunDLL
19-02-2010, 12.54.30
Buongiorno a tutti e grazie per leggere il mio dilemma:
ho fatto un file batch per fare dei bakcup ma questo agisce in modo strano, ovvero il comando:

DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK

mi cancella il file \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI.BCK


ed il comando:

DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\ETICHETTE.BCK

mi cancella il file \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK

Il batch viene lanciato da Windows 2003 Server Small Business.
Qualcuno sa dirmi perchè questo strano sistema? Grazie!

Sergio Neddi
19-02-2010, 13.19.23
Uhm... generalmente utilizzare nomi UNC da linea di comando da problemi, prova a mappare un'unità e poi lavorare sull'unità mappata.

RunDLL
19-02-2010, 14.18.12
Ciao Sergio e grazie per la risposta. Ho provato come mi hai indicato ma purtroppo il problema rimane.

Sergio Neddi
19-02-2010, 22.18.54
Uhm... mi pare strano. lo so che non ci sono spazi nel percorso, ma hai provato ugualmente a racchiudere i path nelle virgolette?
Sicuro sicuro che non sia qualche altro comando nel flusso del batch a fare casino?

RunDLL
19-02-2010, 23.04.00
Grazie di nuovo per la risposta! No a racchiudere tra virgolette non ho provato, sto provando in questo momento con avendo rinominato il file .bat in .cmd
Comunque se hai pazienza ti metto di seguito il file batch, per quanto riguarda eventuali altri comandi che possono fare casino, però ti dico che ho provato anche a lanciare solo il comando del dal prompt e provoca lo stesso problema.

REM CANCELLA I VECCHI BACKUP COMPRESSI "AHRTEST" E "AHR_VM"

DEL /F /Q F:\SQLBACKUP\GIOVEDI*.RAR

REM -----------------------------------------------------------------------------------------


REM VIENE EFFETTUATO IL BACKUP DEI DATABASE "AHRTEST"

OSQL -Usa -P xxxxx -n -Q "BACKUP DATABASE AHRTEST TO DISK = 'F:\SQLBACKUP\GIOVEDI.BCK'"


REM CANCELLA IL VECCHIO DATABASE SU STORAGE E COPIA IL NUOVO

DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI.BCK
COPY /Y /V F:\SQLBACKUP\GIOVEDI.BCK \\STORAGE\PUBLIC\SQLBACKUP


REM COMPRIME IL DATABASE

RAR A -AGDDMMYY F:\SQLBACKUP\GIOVEDI.RAR F:\SQLBACKUP\GIOVEDI.BCK


REM CANCELLA DATABASE

DEL /F /Q F:\SQLBACKUP\GIOVEDI.BCK

REM ------------------------------------------------------------------------------------------


REM VIENE EFFETTUATO IL BACKUP DEI DATABASE "AHR_VM"

OSQL -Usa -P xxxxx -n -Q "BACKUP DATABASE AHR_VM TO DISK = 'F:\SQLBACKUP\GIOVEDI_VM.BCK'"


REM CANCELLA IL VECCHIO DATABASE SU STORAGE E COPIA IL NUOVO

DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK
COPY /Y /V F:\SQLBACKUP\GIOVEDI_VM.BCK \\STORAGE\PUBLIC\SQLBACKUP


REM COMPRIME IL DATABASE

RAR A -AGDDMMYY F:\SQLBACKUP\GIOVEDI_VM.RAR F:\SQLBACKUP\GIOVEDI_VM.BCK


REM CANCELLA DATABASE

DEL /F /Q F:\SQLBACKUP\GIOVEDI_VM.BCK

REM -------------------------------------------------------------------------------------------


REM CANCELLA I VECCHI DATABASE COMPRESSI SUL REV E COPIA I NUOVI DATABASE COMPRESSI SUL REV

DEL /F /Q G:\SQLBACKUP\GIOVEDI*.RAR
COPY /Y /V F:\SQLBACKUP\GIOVEDI*.RAR G:\SQLBACKUP

REM -------------------------------------------------------------------------------------------


REM CANCELLA IL VECCHIO BACKUP COMPRESSO "ETICHETTE"

DEL /F /Q F:\SQLBACKUP\ETICHETTE*.RAR


REM VIENE EFFETTUATO IL BACKUP DEI DATABASE "ETICHETTE"

OSQL -Usa -P xxxxxx -n -Q "BACKUP DATABASE ETICHETTE TO DISK = 'F:\SQLBACKUP\ETICHETTE.BCK'"


REM CANCELLA IL VECCHIO DATABASE SU STORAGE E COPIA IL NUOVO

DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\ETICHETTE.BCK
COPY /Y /V F:\SQLBACKUP\ETICHETTE.BCK \\STORAGE\PUBLIC\SQLBACKUP


REM COMPRIME IL DATABASE

RAR A -AGDDMMYY F:\SQLBACKUP\ETICHETTE.RAR F:\SQLBACKUP\ETICHETTE.BCK


REM CANCELLA IL VECCHIO DATABASE COMPRESSO SUL REV E COPIA IL NUOVO DATABASE COMPRESSO SUL REV

DEL /F /Q G:\SQLBACKUP\ETICHETTE*.RAR
COPY /Y /V F:\SQLBACKUP\ETICHETTE*.RAR G:\SQLBACKUP

REM CANCELLA DATABASE

DEL /F /Q F:\SQLBACKUP\ETICHETTE.BCK

REM -------------------------------------------------------------------------------------------

Sergio Neddi
19-02-2010, 23.19.48
Vedrò di fare qualche prova, anche se non so se ne avrò il tempo e quindi non prometto niente.

RunDLL
19-02-2010, 23.21.24
Grazie comunque!

Semi.genius
19-02-2010, 23.34.58
Sembra solo un problema di write-back caching.


DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK

mi cancella il file \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI.BCK


ed il comando:

DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\ETICHETTE.BCK

mi cancella il file \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK


Questo perché l'operazione precedente era DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI.BCK perciò il flush è stata forzato dall'altro comando di cancellazione.

http://technet.microsoft.com/en-us/sysinternals/bb897438.aspx

Se dopo ogni commando di cancellazione, esegui Sync sull'unità scelta (mappa l'unità perciò), la cancellazione avviene al momento giusto?

...non sono sicuro che funzioni via rete pero'. Pero' puoi disabilitare la write-back caching da gestione periferiche del disco interessato alla scrittura

RunDLL
21-02-2010, 10.29.49
Ciao semi.genius e grazie per la risposta. Per "esegui Sync" cosa intendi?
Da gestione periferiche non vedo il disco in cui vengono prima copiati i file e poi cancellati perchè è un NAS.
Sono stato davanti al computer a "sorbirmi" tutto questo batch per vedere che succedeva (2 ore quasi).
GIOVEDI.BCK non viene cancellato perchè non esiste sul nas in quanto, come ho già detto, i successivi comandi DEL cancellano il file .bck a prescindere da come si chiama.
Poi però al successivo comando COPY /Y /V F:\SQLBACKUP\GIOVEDI.BCK \\STORAGE\PUBLIC\SQLBACKUP il file GIOVEDI.BCK viene regolarmente copiato su nas e rimane là fino a che il batch non lancia il comando DEL /F /Q \\STORAGE\PUBLIC\SQLBACKUP\GIOVEDI_VM.BCK.
Ma se gli dico di cancellare "giovedi_vm.bck perchè mi cancella giovedi.bck che ha un altro nome?
E così via con tutti i file .bck, addirittura "DEL etichette.bck" mi cancella "giovedi_vm.bck" che manco s'assomigliano come nome.
È come se, se gli dico di cancellare un file .bck mi cancella il file .bck che trova a prescindere da come si chiami il file.

LoryOne
21-02-2010, 10.58.02
A mio avviso bisogna considerare diversi aspetti:
Primo fra tutti il fatto che i comandi batch vengono eseguiti in modo asincrono, quindi non è detto che il processo successivo attenda il termine del precedente prima che si avvii. In questo caso potresti utilizzare il comando start ... /wait dove è necessario tempo perchè l'operazione sia conclusa in locale e trasferita completamente sul NAS.
In secondo luogo, quando hai a che fare con i caratteri jolly ?*, devi prestare attenzione a come vengono interpretati. In questo caso 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.
I percorsi UNC spesso vengono sostituiti dalla mappatura dello stesso percorso su drive identificato da una lettera per evitare un problema legato alla lunghezza del percorso che ha un valore fisso nell'API di riferimento, quindi hai fatto bene a procedere in questo modo, anche se a quanto vedo la limitazione dei 256 caratteri nel percorso non l'hai sicuramente raggiunta.

Sergio Neddi
21-02-2010, 11.30.40
A mio avviso il problema potrebbe dipendere dal fatto che l'unità di lavoro non ha quasi sicuramente Windows, presumibilmente è un NAS basato su Linux o chissà cosa. Potrebbe avere quindi un file system bizzarro per alcuni versi.
Occhio che con sistemi strani talvolta si possono avere sorprese con i nomi dei file. Ad un mio collega è capitato che il trattino di sottolineato veniva interpretato come asterisco.
Addirittura, se il simbolo _ venisse interpretato come termine del nome allora GIOVEDI_VM.BCK e GIOVEDI.BCK verrebbero visti nella stessa maniera, GIOVEDI.BCK.
Provare a cambiare il nome dei file per vedere se dipende da questo?

RunDLL
21-02-2010, 15.37.23
Grazie a tutti per le risposte. I caratteri giolli sono utilizzati per cancellare dei file compressi in RAR dal disco locale del server, questi comandi non danno nessun problema, i comandi che non funzionano devono cancellare dei file in un NAS, i percorsi utilizzati nel comando DEL non hanno caratteri jolly.
Il NAS non ha un sistema operativo Windows, come dici tu giustamente Sergio, ha un sistema operativo suo proprietario, non saprei adesso se è basato su Linux.
Comunque nel frattempo ho provato anche come mi avevi suggerito ovvero a mettere le virgolette nel percorso ma non è servito. Ora proverò anche con nomi file di massimo 8 caratteri, vediamo che succede.
Il fatto che ci sia l'underscore penso che non sia determinante perchè poi la cancellazione del file "etichette.bck" che non ha l'underscore oltre ad essere un nome totalmente diverso e nemmeno somigliante, va a cancellare il file "giovedi_vm.bck".
Comprendo anche il sistema asincrono dei file batch ma come può un sistema che non rispetta la sequenzialità o non aspetta la fine di un processo lanciato precedentemente, cancellare un file che ha un nome diverso da quello che gli dici di cancellare? :mm:

Semi.genius
21-02-2010, 15.53.49
Che NAS è? Se è basato su linux si può disabilitare il write cache back così mi faccio convinto che non sia semplicemente quello il problema :x:

Se è prioritario bisogna vedere la documentazione. Non credo che cancelli sequenzialmente, bensì cancella il file precedente all'esecuzione del commando corrente

LoryOne
21-02-2010, 18.30.25
i comandi che non funzionano devono cancellare dei file in un NAS

I comandi shell tipo dir,del o copy via rete che utilizzino TCP/IP come protocollo di trasporto si appoggiano ad SMB. A dirla tutta, ognuno dei comandi elencati ricava l'indirizzo del server, poi crea una comunicazione interprocesso verso di esso in modo del tutto trasparente per eseguire il comando attraverso una chiamata alla hidden pipe (IPC$) via RPC.


Il NAS non ha un sistema operativo Windows, come dici tu giustamente Sergio, ha un sistema operativo suo proprietario

Quale file system è in uso su quel NAS ?


cancellare un file che ha un nome diverso da quello che gli dici di cancellare?

Il NAS ha ricavato il nome del file via rete e sa identificarlo sul file system che è in uso ?
Ha compreso quale comando deve eseguire sul file archiviato ?

RunDLL
21-02-2010, 22.23.18
Allora... Intanto grazie per l'impegno che state mettendo per aiutarmi.
Il NAS è un EM4071 della Eminent.
La possibilità di scrivere la cache non ce l'ha, comunque ho guardato la pagina di configurazione e vedo che ha un server Samba. L'hard disk è formattato con NTFS.
Comunque... Nel backup della domenica, oggi ho modificato il batch chiamando i file .bck con nomi massimo di 8 caratteri e senza simboli come l'underscore.
Stasera ha copiato sul NAS tutti i file .bck senza cancellarli.
Ho modificato anche il file di domani lunedì con lo stesso criterio, staremo a vedere se va tutto ok e quindi si è risolto il problema.
Comunque questo NAS mi ha dato sempre problemi, ogni tanto bisogna spegnerlo perchè non si rileva in rete, una volta ho dovuto resettarlo perchè non mi prendeva più un comando, non riuscivo nemmeno ad entrare nella pagina della configurazione, un'altra volta non mi formattava l'hard disk, ho dovuto staccare la ventola perchè ad un certo punto faceva un casino micidiale e leggo in rete che è una cosa frequente. E questa è un'ulteriore esperienza negativa con oggetti Eminent, belle scatole, belle presentazioni ma mi sa che le cose valgono poco.

LoryOne
22-02-2010, 08.48.42
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
22-02-2010, 09.29.43
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
22-02-2010, 10.35.02
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
22-02-2010, 11.05.17
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
22-02-2010, 13.42.45
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
22-02-2010, 21.19.47
Giustissimo Sergio (Y), ogni intervento può essere motivo di approfondimento. :)

Sergio Neddi
22-02-2010, 22.17.27
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
23-02-2010, 13.26.34
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.

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.

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
23-02-2010, 14.37.00
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
23-02-2010, 22.19.57
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
23-02-2010, 22.31.19
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
23-02-2010, 22.50.36
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
23-02-2010, 23.34.06
NASfiga...