Newsgroup: it.comp.os.linux.sys
Titolo: SMB e data di creazione del file

Sto investigando alcuni problemi di sincronizzazione, e ho trovato 
questa strana cosa:
un file creato oggi da un client windows, ha la data di creazione in 
ritardo di un giorno:
file bbb.par
bbb.par: CDF V2 Document, Little Endian, Os: Windows, Version 5.1, Code 
page: 1252, Locale ID: 1040, Title:  , Subject:  , Author: STI, 
Keywords:  , Template: Normal-Ferro.par, Last Saved By: STI, Revision 
Number: 1, Create Time/Date: Sun Mar 20 14:43:13 2011, Last Saved 
Time/Date: Sun Mar 20 14:43:13 2011, Number of Pages: 0, Number of 
Words: 0, Number of Characters: 0, Name of Creating Application: Solid 
Edge, Security: 0
mentre oggi e' Lunedi 21 marzo.
Se invece interrogo il file system con ls -l, mi viene restituita la 
data corretta. Forse "file" non e' il comando adatto per queste operazioni?
Sia il client windows che il server linux hanno la data di sistema corretta
client: Win XP HE SP3
Server Slack 13.1 31 bit  con Samba 3.5.7

 operazioni?
Beh, "file2 serve per conoscere il tipo di file. Come poi faccia a darti 
tutte quelle informazioni non lo so, forse c'è una alias da qualche parte.
prova a fare:
type file
Nicola
-- 
chi va pian va san e va lontan

> ritardo di un giorno:
La butto li: in linux non esiste la data di creazione, quindi quella che 
vedi è necessariamente un meta-dato scritto da windows all'interno del file.
E se il client windows avesse davvero la data avanti un giorno.. ?
Ale


sti@server:/sti/temp$ type Parte1.par
Parte1.par is ./Parte1.par
Cosa dovrei vedere con questo comando?

 Ale
No, sia il client che il server hanno la data corretta.


Forse meglio uno stat?


Gia' questo fornisce un risultato in accordo con ls:
sti@server:/sti/temp$ stat Parte1.par
   File: `Parte1.par'
   Size: 209408          Blocks: 424        IO Block: 4096   regular file
Device: 813h/2067d      Inode: 4440163     Links: 1
Access: (0744/-rwxr--r--)  Uid: (  501/     sti)   Gid: (  501/     sti)
Access: 2011-03-22 08:18:57.000000000 +0100
Modify: 2011-03-22 08:18:58.000000000 +0100
Change: 2011-03-22 08:14:11.000000000 +0100

Ale wrote:

Veramente avevo detto "type file" per sapere da dove arriva il comando 
"file". Non intendevo il TUO file :)
Nicola.



Ah! :-)
sti@server:/sti/temp$ type file
file is /usr/bin/file


Quindi qual'è il problema?
Che file da la data sbagliata? Allora non usare file :)
Secondo me, andando a frugare dentro il file stesso, ti fa vedere la
data di creazione del file, scritta dal programma specifico.
Se andasse dall'os, ti direbbe quella giusta.
Sicuramente ha la sua utilità l'uso dell'informazione all'interno del
.par. Stile gli exif per le immagini.
Michele


Il mio problema e' che uso UNISON per sincronizzare due file system 
remoti (entrambi su linux), e a volte capita che sincronizzi al 
contrario, cioe' sovrscrvie il file piu' vecchio su quello piu' nuovo, 
causando la perdita delle ultime modifiche fatte.
L'errore non e' sistematico, sto quindi cercando di capirci qualcosa.

Ale ha scritto:

Ma unison usa file e non stat? (o la syscall relativa) Non ci credo!
Ma perché non usare rsync con doppio passaggio con opzione -u ?
Ciao




E' probabile che sia un problema di clock sync (le macchine Windows tra
l'altro credo che sincronizzino con una precisione di 2 secondi; e - se
non ricordo male - e' accettabile 60 come valore dei secondi... e' raro
ma succede pure questo.
Per questo motivo vari software di syncing hanno una "time window", gli
puoi dire "due file con delta-timestamp < Ns hanno timestamp uguale".
Leonardo
-- 
Enough, enough!  But, stranger, ere we part,
Glancing farewell to each nefarious bier,
This warning would I beg you take to heart:
There is an end to e'en the worst career!

 No, sia il client che il server hanno la data corretta.
... ma se uno interpretasse la data dell'altro come settata su GMT ?
(la butto lě)
ciao, f.

... ma se uno interpretasse la data dell'altro come settata su GMT ?
In Italia la differenza è di un'ora.
Qui manca un giorno.
-- 
Ci sono 10 tipi di persone al mondo: quelle che capiscono il sistema binario
e quelle che non lo capiscono.


In realta' mancano 25 ore esatte, per cui l'idea di cujo potrebbe non 
essere sbagliata.
Comunque ora ho installato l'ultima versione di Unison, che fino a ieri 
non si compilava sul processore ARM di uno dei due server, vediamo come va.
Grazie a tutti per ora.

 Qui manca un giorno.
D'oh ! ;)
C'e' scritto "un giorno", si ;), io però continuavo a leggere "un'ora"
;)
era tardi, sorry ;)
ciao, f.

 causando la perdita delle ultime modifiche fatte.
Sono ignorante, ma mi pare che unison funzioni in entrambi i sensi al 
contrario di rsync. Quindi la cosa non mi stupisce. Tutto molto IMHO.
Nicola.


Ale wrote:

Ok, il tuo comando "file" sulla slack è più figo del mio comando "file" su 
ubuntu. (Grrrrr).



Ma non penso :-), se provo a dare "file" a un file openoffice mi ritorna 
una stringa banalissima:
sti@server:/sti/temp$ file test.odt
test.odt: OpenDocument Text
Prova a fare un test simile con un file doc, viene fuori una info molto 
piu' lunga:
sti@server:/sti/temp$ file test.doc
test.doc: CDF V2 Document, Little Endian, Os: Windows, Version 1.0, Code 
page: -535, Revision Number: 1, Total Editing Time: 00:27, Create 
Time/Date: Tue Mar 22 12:58:14 2011, Last Saved Time/Date: Tue Mar 22 
12:58:38 2011
(il doc e' creato con OpenOffice!).

ubuntu. (Grrrrr).
which?


 piu' lunga:
Ah, è vero! Ora sono sto meglio :)
