Newsgroup: it.comp.os.linux.iniziare
Titolo: mi serve una distribuzione/file system che...

mi serve una qualunque distribuzione che mi dica per i file su disco 
qual e' la data di creazione
 
meglio ancora se puo' essere visualizzato con un file manager grafico 
(non c'e' problema.. puo' essere qualsiasi file manager di qualsiasi 
desktop gnome, kde, mate ecc ecc ecc.. l'importante e' che indichi 
questa cavolo di data di creazione)
 
quale filesystem usare??


La cosa non è semplice perché occorrerebbe definire cosa sia la data di 
creazione di un file: ad esempio se io creo un file con touch 
miofile.txt in data data1 e poi in data2 lo edito  e ci scrivo l'elenco 
della spesa ed in data3 lo edito e ci scrivo una lettera quale è la sua 
data di creazione?
Comunque puoi sempre usare la convenzione di chiamare un file 
YYYYMMGG_myfilename.

 ....
 
No! A te serve un filesystem che memorizzi l'orario di creazione.
 
Ora potrei parlarti per ore sul perché l'orario di creazione non è
usato nei filesystem di Unix e sul perché non sarebbe una buona 
idea inserirlo ma l'unica risposta possibile è: scordatelo, sui 
filesystem UNIX l'orario di creazione non è affidabile.
 
Se per te è tanto importante cambia sistema operativo.
 
 
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

> Se per te è tanto importante cambia sistema operativo.
 
e' da una vita che vorrei buttare un pc sopra windows ma non lo posso 
fare per colpa di questa cavolo di data di creazione..
 
possibile che non verra' mai implementato?
 

 data di creazione?
 
per me e' quella in cui il file viene creato.. insomma mi serve un 
sistema che ragiona come ragiona windows..
 
devo poter cercare delle foto in base alla data di creazione..

 possibile che non verra' mai implementato?
 
Hai cercato con con il tuo motore di ricerca
preferito?
Hai trovato che, in certi situazioni e`
possibile trovare la data di creazione?
 
bye,
 
-- 
 
piergiorgio

 possibile trovare la data di creazione?
 
ti riferisci a usare debugfs ?
io dicevo quando verra implementato che uno fa: tasto destro proprieta' 
su un file e zac ti dice l'orario di creazione...

 devo poter cercare delle foto in base alla data di creazione..
 
Puoi avere un'idea approssimata guardando la sua posizione di scrittura
nel fs, cioe' dando: "\ls -lU" nella directory che li contiene.
 
-- 
Tanti saluti
 

 su un file e zac ti dice l'orario di creazione...
 
Probabilmente mai, ma se "debugfs" funziona,
puoi usarlo per cambiare il nome del file
in maniera opportuna (con uno script).
 
bye,
 
-- 
 
piergiorgio

 

Ad ogni modo, secondo questa tabella:
 
https://en.wikipedia.org/wiki/Comparison_of_file_systems#Metadata
 
 
Vi sono filesystem, per Linux, con "crtime"
(creation time).
 
La domanda successiva e`, se questo "crtime" sia
accessibile facilmente o meno.
 
bye,
 
-- 
 
piergiorgio

 devo poter cercare delle foto in base alla data di creazione..
 
Meta Tracker, Beagle o Nepomuk/Baloo indicizzano i metadati dei file. In 
particolare, le foto di solito hanno tra i dati Exif la data creazione. 
Infine, Digikam o l'equivalente per GNOME permettono di cercare le foto per 
data di creazione. Ergo, ci sono molti modi per cercare dei file in base 
alla data di creazione, che non deve essere necessariamente un metadato 
specifico sul file
 
Enrico

 specifico sul file
 
Ho provato con una mia foto, nominata 'svasso_maggiore_1.jpg'. Nel
file-manager Natilus vedo soltanto la data di modifica: 15 Ott 2013, ma
se controllo nelle proprieta` mi appare questa finestra con la data
dello scatto, cioe` il 14 Ott 2013 :
 
http://postimg.org/image/44jjxstu5/
 
 
La stessa data la ottengo da terminale con
 
identify -verbose svasso_maggiore_1.jpg | grep "exif:DateTime:" | awk -F' ' '{print $2" "$3}'
2013:10:14 15:02:43
 
 
 
 

 accessibile facilmente o meno.
 
Per quanto leggo qui:
https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout#Inode_Timestamps
 
non sembra cosi` immediato.
 
There is also a fifth timestamp to record inode creation time (crtime);
this field is 64-bits wide and decoded in the same manner as 64-bit
[cma]time. Neither crtime nor dtime are accessible through the regular
stat() interface, though debugfs will report them.
 
 
 

 possibile che non verra' mai implementato?
 
Chi ha mai detto che non sarà mai implementato? Solo che il /creation/
/time/ è non è standard, ti lega al particolare /filesystem/ e non è così 
utile. 


 accessibile facilmente o meno.
 
Ti riferivi a quanto sopra o ad altro?


 in maniera opportuna (con uno script).
 
LOL



Non è implementato a livello di kernel api ma per alcuni filesystem la 
creation_date è scritta nell' inode
 
Per leggere basta una cosa del genere (a parte iniettare l' api):
 
 
  sudo debugfs -R "stat <filename>"  /dev/sdXXX | grep crtime
 
Questo è per ext4,altri filesystem potrebbero cambiare il nome 'crtime'
 
 
con filename il path assoluto non partendo dalla radice del filesystem 
ma dalla radice della partizione
 
Esempio:
 
ho un file chiamato /home/utente/pippo.txt  con /home montata su /dev/sda2
 
  sudo debugfs -R "stat /utente/pippo.txt"  /dev/sda2 | grep crtime
 
 
 
 
 
 


se si tratta di foto c'è exiftool

 fotografie ti avrei consigliato DigiKam, che, tra l'altro. uso.
 
bah
sono sempre stato contrario a usare software per catalogare le foto..
poi sono sempre stato utente gnome ed e' come se avessi dei preconcetti 
verso i software kde..
 
 
 


 
a parte che per fare l'interrogazione di un file con debugfs ci vuole un 
casino di tempo..
moltiplicato per oltre 300gb di foto... siamo a cavallo
 
e poi ammesso che i file vengano rinominati.. diventa un casino per fare 
la ricerca per es. da una data a un'altra
 
 

 la ricerca per es. da una data a un'altra
 
No, tu non usare un sistema di indicizzazione.


 verso i software kde..
 
E allora San Google ti dirà quali equivalenti per Gnome ci 
sono [...] fanciullo!


 fare la ricerca per es. da una data a un'altra
 
Anziche` rinominare non ti andrebbe bene modificare la data di modifica
sostiutuendola con la date di scatto?
 
Ho fatto una prova per una sola foto, che nel mio caso si chiama
'svasso_maggiore_1.jpg', collocata nella stessa directory dello script.
 
[CODE]
 
#!/bin/bash
FOTO="svasso_maggiore_1.jpg"
duepunti=":"
slash="/"
clear;
echo "data modifica di $FOTO: "; ls --full-time $FOTO
echo
echo
datascatto=$(identify -verbose $FOTO | grep "exif:DateTime:" | awk -F' ' '{print $2}')
dataformattata=${datascatto//$duepunti/$slash}
echo "data di scatto: $dataformattata"
echo
orascatto=$(identify -verbose $FOTO | grep "exif:DateTime:" | awk -F' ' '{print $3}')
echo "ora di scatto: $orascatto"
echo
nuovotimestamp="$dataformattata $orascatto"
echo
touch --date "$nuovotimestamp" $FOTO
echo "nuova data modifica di $FOTO: "; ls --full-time $FOTO
exit 0
 
[/CODE]
 
 
 
 


 
 
Ciao, ho appena provato con un file che ho creato e poi modificato dieci 
minuti più tardi. Purtroppo mi restituisce la data di modifica, 
nonostante abbia ext4. Il file l'ho creato alle 09:19, ma guarda cosa 
dice il comando che ho lanciato:
 
 
debugfs -R "stat /home/andrea/Desktop/prova"  /dev/sda6 | grep crtime
debugfs 1.42.8 (20-Jun-2013)
crtime: 0x54c357da:240137c8 -- Sat Jan 24 09:29:14 2015
 
Sembra proprio che non funzioni, perchè?
 
Scorpion77

 Sembra proprio che non funzioni, perchè?
 
Vedi se capisci questo scenario:
Creo un file nuovo con VIM. Scrivo le mie cose. Esco e salvo con :wq
Il giorno dopo apro quel file. Aggiongo delle cose. Esco e salvo con :wq
VIM vede se c'è un backup ed eventualmente lo cancella. VIM rinomina
il file originale aggiungendo la tilde. Vim crea un nuovo file, lo chiama 
come il vecchio, ci scrive i dati che tu hai modificato. VIM termina.
Hai capito questo scenario?


 Hai capito questo scenario?
 
Si, ma questo e` un "problema" di come vim
tratta i file, non ha nulla a che vedere
con il fatto che un fs non abbia "crtime".
 
Io vedo un'altra situazione, simile, ma
non necessariamente uguale.
 
Precisamente l'uso di "mv".
 
Se "sposto" un file sullo stesso device,
allora questo e` un rename (perche` il nome
del file e` tutto il path+nome), quindi il
"crtime" *dovrebbe* rimanere uguale (stesso
file, creato al momento X).
Se pero` il device e` diverso, allora il
file deve essere *copiato*, quindi un
nuovo file deve essere creato, con nuovo
"crtime", ovviamente (altrimenti il comando
"copia" dovrebbe prendersi cura di barare
sul "crtime").
 
Quindi vi sono due situazioni uguali in cui
il "crtime" risulta diverso.
 
Immagino vi siano altri scenari possibili.
 
Da cui si deduce che o si crea uno standard
su come gestire il "crtime" oppure non lo
si usa affatto.
 
Da notare che con Windows e` possibile
*cambiare* il "crtime" di un file, quindi
neanche il quel caso e` affidabile.
 
bye,
 
-- 
 
piergiorgio

 neanche il quel caso e` affidabile.
 
Non ho detto che le cose siano diverse su Windows, anzi per
molti versi sono esattamente le stesse.
 
PS  Quando ho consigliato un sistema operativo diverso mi 
       riferivo a OpenVMS
 

        riferivo a OpenVMS
 
Interessante, gestisce il fs come un revision
control?
 
bye,
 
-- 
 
piergiorgio


Sei proprio sicuro di averlo solo modificato e non ricreato ex novo ?
 
Una prova:
 
cd tmp  # una dir. per provare
 
rm -f pippo # cancella l' eventuale esiste
 
 
echo > pippo  # crea il file vuoto
 
sleep 10 # attende 10 secondi
 
echo 'prova' > pippo # modifica il file
 
sudo debugfs -R "stat <utente>/tmp/xx"  /dev/sdXXX | grep time   # 
visualizza i tempi
 
 
 
 
 

 Sei proprio sicuro di averlo solo modificato e non ricreato ex novo ?
 
Devo dire che anche io ho notato strane cose.
 
Ho un file in cui "crtime" e` circa un anno
nel futuro rispetto agli altri "time".
 
In teoria, "crtime" dovrebbe essere sempre
nel passato rispetto agli altri, credo.
 
bye,
 
-- 
 
piergiorgio

 Interessante, gestisce il fs come un revision control?
 
Credo che tu abbia esperienza solo di /Software/ /Revision/
/Control/ come Subversion, Git, Mercurial, etc. Invece VMS 
aveva un /versioning/ /filesystem/ che è tutta un'altra cosa.
Si stanno sperimentando diversi /versioning/ /filesystem/
nativi su Linux ma la strada è ancora lunga. Nel frattempo
accontentiamoci di Subversion e Git che perà sono solo delle 
pezze a colore.
 

 No, tu non usare un sistema di indicizzazione.
 
Cosa ci ti puoi aspettare dal solito Alex? :-/
 
 
 


direi proprio di
Forse un errore sul filesystem
 
prova con un e2fsck,dovrebbe rilevare l' errore e se vuoi,correggerlo
 

 Cosa ci ti puoi aspettare dal solito Alex? :-/
 
Seguo la massima di mio nonno: "Guaglio', non disprezzare
niente perché pure la merda diventa concime" per cui il mio 
killfile è quasi sempre vuoto e non leggo mai le intestazioni.
 
Comunque vedo che anche altri hanno sentito la puzza di kane.
Ma come si fa!
 
Nonostante  l'argomento di merda, è venuto fuori che non tutti
conoscono i filesystem con le versioni; interessante.
 

 prova con un e2fsck,dovrebbe rilevare l' errore e se vuoi,correggerlo
 
Nope, "fsck" gira regolarmente e non
trova nulla...
 
Probailmente "fsck" ignora quel field.
 
bye,
 
-- 
 
piergiorgio

> echo 'prova' > pippo # modifica il file
 
Questo comando non modifica il file , ne crea uno nuovo e lo sostituisce.
 
Per fare una pura modifica dovresti fare una append >>  specificando prima una seek 0,
non credo sia possibile.
 
Giulia
 
 

 Questo comando non modifica il file , ne crea uno nuovo e lo sostituisce.
 
In realtà, se vogliamo esser precisi, non crea un nuovo file.
Tronca l'esistente a zero e poi vi scrive dentro.
 
Se provi vedrai che il numero di inode del file non cambia con la 
redirezione, cosa che invece avverrebbe se si trattasse di un nuovo 
file. E' importante perché 
p.es
. nel caso di log in cui non si vuole o 
non si può fermare l'applicazione, un copy del file seguito da un 
truncate dello stesso permette all'applicazione di continuare a scrivere 
i suoi dati senza essere interrotta (opzione copytruncate di logrotate).
 
 
-- 
Flavio Visentin
 
Scientists discovered what's wrong with the female brain: on the left
side, there's nothing right, and on the right side, there's nothing left


strace bash -c '> pippo' | grep open | grep pippo
 
sia nel caso che il file esista o non esista la bash fa sempre
 
open("pippo", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 3
 
 
se il file già esiste la O_CREATE non ha effetto:
 
O_CREAT
If the file exists, this flag has no effect except as noted under O_EXCL 
below
 
 
Tratto dal man di open
 
E se la O_CREATE non ha effetto la data di creazione non viene modificata
 
 
 

 file. ...
 
Invece no. Gli inode vengono riciclati e spesso specialmente su 
sistemi con poco carico e con un solo utente, puoi creare e 
cancellare decine e decine di volte dei file prima che cambi 
il numero di inode. Provare per credere 
 
while :; do
  touch pippo
  ls -il --full-time pippo
  rm -f pippo
  sleep 1
done
 
 
 

 Invece no. Gli inode vengono riciclati
 
Ovviamente vengono riciclati, altrimenti andrebbero ben presto esauriti, 
specie su filesystem con un numero di inode predefinito.
Ma la politica di riciclaggio dipende dal filesystem e non è affatto 
detto che venga riattribuito lo stesso inode. Su btrfs per esempio, il 
FS che ho sul mio PC, non si ricicla mai l'inode appena cancellato 
(presumo sia per via della modalità CoW di btrfs).
 
root@fuppa:/tmp# while :; do
 >   touch pippo
 >   ls -il --full-time pippo
 >   rm -f pippo
 >   sleep 1
 > done
400229 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:19:53.287149999 
+0100 pippo
400230 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:19:54.307162308 
+0100 pippo
400231 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:19:55.317174497 
+0100 pippo
400232 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:19:56.327186685 
+0100 pippo
^C
 
Mentre su ext o reiserfs può accadere, a patto che non vi siano altre 
scritture contestualmente all'operazione.
 
dumbo:/tmp# while :; do
 >   touch pippo
 >   ls -il --full-time pippo
 >   rm -f pippo
 >   sleep 1
 > done
394019 -rw-r--r-- 1 root root 0 2015-01-26 00:21:34.940369926 +0100 pippo
394019 -rw-r--r-- 1 root root 0 2015-01-26 00:21:35.947005800 +0100 pippo
394019 -rw-r--r-- 1 root root 0 2015-01-26 00:21:36.953641675 +0100 pippo
394019 -rw-r--r-- 1 root root 0 2015-01-26 00:21:37.960277549 +0100 pippo
^C
 
Nel caso del truncate invece non è una questione di riciclaggio di inode 
che viene ricreato con lo stesso numero (o meglio riallocato), ma è 
proprio lo stesso identico inode che non viene toccato se non per i 
valori di dimensione e data di ultima modifica/accesso, esattamente come 
una modifica qualsiasi. Tant'è che anche su btrfs il numero di inode non 
cambia a differenza dell'operazione di unlink.
 
visentin@zipmantp:/tmp$ while :; do > pippo;   ls -il --full-time pippo; 
sleep 1; done
400243 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:24:59.560832208 
+0100 pippo
400243 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:25:00.567511256 
+0100 pippo
400243 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:25:01.574190184 
+0100 pippo
400243 -rw-r--r-- 1 visentin visentin 0 2015-01-26 00:25:02.577535739 
+0100 pippo


 Immagino vi siano altri scenari possibili.
 
su windows mi pare che se copi un file da un computer all'altro, quindi 
sul secondo pc i file vengono creati ex novo, la data di creazione e' 
quella del file, non e' il momento in cui vengono creati sul secondo pc
 
e questa e' una cosa buona per chi cerca in base alla data di creazione
 


Si, ma questo vuol dire che la data di
creazione e` "creata" arbitrariamente.
 
Cioe` non e` la data di creazione.
 
Come scrivevo prima, e` un problema piu`
filosofico che altro.
 
Una copia non e` altro che un filtro senza
operazioni.
 
Che differenza c'e` tra una copia e, per
esempio, una conversione da gif a jpeg?
 
Tecnicamente *nessuna*, sono tutte e` due
copie, solo che la prima ha un "filtro" che
non modifica nulla, la seconda ha un "filtro"
che cambia i dati.
 
Per quale motivo i file risultanti dovrebbero
avere due date di creazione diverse?
 
In fondo, anche la conversione da gif a jpeg
non cambia nulla...
 
bye,
 
-- 
 
piergiorgio

 Che differenza c'e` tra [TAGLIO]
 
Codesti discorsi appartengono alla terza categoria e perciò non 
mi interessano.


 mi interessano.
 
E quindi perche` questo reply?
 
La mia argomentazione non era mica rivolta a te...
 
Boh...
 
bye,
 
-- 
 
piergiorgio

 file-manager Natilus
 
che non e` Digikam o l'analogo per GNOME per la gestione delle foto tramite 
Exif. Senza contare che, se non viene installata l'apposita estensione, 
Nautilus non cerca nei metadati della foto, ma nei metadati nel file system. 
Ergo, Nautilus non e` lo strumento giusto :)
 
Enrico

 La mia argomentazione non era mica rivolta a te...
 
Ci mancherebbe pure. Comunque stiamo facendo una discussione 
civile (si spera), vediamo di non uscire fuori tema, per esempio
parlando di /versioning/ /filesystem/ argomento interessante ma 
fuori tema.


 /copy-on-write/ che si usa già da molto tempo.
 
Tu stai confondendo principio con implementazione.
 
La COW e` solo un *implementazione*, o meglio e`
un ottimizzazione della cosa.
 
Il fatto che la copia sia "modellabile" come filtro
e` un fatto noto e riconosciuto in ambiente informatico.
Che poi la copia avvenga o meno, o che sia fatta in
COW o meno *non* e` assolutamente rilevante.
 
Peccato poi solo per una cosa.
Il mio esempio (gif/jpeg) e` *identico* al tuo su "vi".
 
Quello che si *deve* capire che vi e` differenza
tra considerare un file come un gruppo di byte,
oppure come un contenitore di dati.
 
Un file e la sua versione compressa hanno byte
diversi, ma lo stesso preciso contenuto (tant'e`
che diversi file manager mostrano i due casi in
maniera indistinguibile).
 
Quindi, la data di creazione un file compresso
deve essere quella del file originale oppure
quella del momento della creazione del archivio?
 
Questo non e` diverso da quello che scrivi tu.
 
bye,
 
-- 
 
piergiorgio

 Questo non e` diverso da quello che scrivi tu.
 
Dato che stai facendo l'esempio di un filesystem compresso 
non c'è dubbio queste due versioni sono lo stesso file e devono 
avere gli stessi attributi tranaan forse che il file compresso può
evere un attributo che indica che è compresso.
 
Però fai attenzione che stai parlando di dettagli implementativi 
di un tipo di filesystem diverso da quello che stiamo parlano
e rientra nella categoria farneticazioni proprio perchè non ci
appizza.
 
 
 
 

 E per Unix/Linux i file sono sequenze di byte.  
 
Ovviamente i file sono sequenze di byte per il SO.
La domanda e` cosa sono per l'utente.
 
L'OP vuole ordinare/cercare i file (foto, mi pare
di ricordare) per data di creazione.
Se io converto il jpeg in raw (che e` assolutamente
*identico* al jpeg come immagine), devo conservare
la data di creazione del jpeg o serve una nuova?
 
Probabilmente, dal punto di vista tecnico, avra` una
data nuova.
Nota che i file sono diversi, ma il contenuto e`
esattamente lo stesso e, come utente, io sono piu`
che altro interessato al contenuto non nel senso
di come sono messi i byte.
A me (non so all'OP), come utente che vuole avere la
data di creazione come riferimento, farebbe comodo
avere la stessa data (o forse no).
 
Quindi, la domanda e`: quando si deve conservare la
stessa data di creazione e quando, invece, questa
deve essere conservata?
 
Dato che questo dipende da cosa l'utente vuole farci
con questa data e con il file, direi che la questione
e` "filosofica", nel senso che dipende da come uno
vede il problema.
 
bye,
 
-- 
 
piergiorgio

  [...skip useless discussion...]
 
...