Discussion:
Proof of concept per un programma di scansione duplicati.
(too old to reply)
unknown
2013-06-19 09:20:00 UTC
Permalink
Ciao lista,

In casa mi sono fatto un Severino con Debian, come tutti sappiamo, quando
si hanno a disposizione questo spazi si comincia a buttare dentro roba
senza pensarci più di tanto.

Ora mi ritrovo con una marea di file duplicati, a volte anche con nomi
diversi... ho privato diversi programmi che dovrebbero trovare tutti i
duplicati, ma per un verso o per l'altro non mi hanno mai soddisfatto.

Visto che si tratta di un file server, quindi senza interfaccia, pensavo ad
un qualcosa diviso in due parti... il motore vero e proprio e
un'interfaccia web che permetta di esaminare il risultato
dell'elaborazione, che per il modello di scansione e per la quantità di
materiale potrebbe metterci anche qualche giorno. Per di più esaminare il
risultato non è un'operazione immediata, ci potrebbero volere diverse
sessioni di lavoro sulla pagina web. La cosa interessante sarebbe riuscire
a far rimanere attivo il processo in background che analizzi i nuovi file
inseriti nella directory considerata.

Va da se che per poter fare una cosa che sui prolunghi nel tempo bisogna
costruire una struttura dati adeguata e avere un sistema di memorizzazione
su una qualche forma di DB.

La struttura dati che ho pensato è relativamente banale, un dizionario in
cui si usa una tupla come chiave e una lista come dato. La tupla conterrà i
seguenti dati:
- la dimensione del file (banale stat)
- il tipo di file (il responso del comando file, o il corrispettivo python
se esiste)
- il calcolo md5sum del file (questa è sicuramente la parte più onerosa in
termini di tempo di calcolo)

Mentre la lista di dati è molto semplicemente l' elenco dei file che
condividono gli elementi usati per generare la chiave.

Ora... se per la parte di scansione e generazione del dizionario, credo di
non avere problemi, per la gestione del DB e della parte web non saprei
proprio da che parte girarmi... per la gestione come deamon ci si può
pensare successivamente.

Per il DB, mi avete distrutto il mito di maisequel, cosa mi consigliate?
Postgress o SQLite?

Per la gestione del web? Implementare qualcosa con django?

Byez
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130619/5c0b6bc5/attachment-0001.html>
unknown
2013-06-19 09:49:21 UTC
Permalink
Post by unknown
Ora mi ritrovo con una marea di file duplicati, a volte anche con
nomi diversi... ho provato diversi programmi che dovrebbero trovare
tutti i duplicati, ma per un verso o per l'altro non mi hanno mai
soddisfatto.
Quali programmi hai provato?

Nei repo Ubuntu trovo:

- FSlint <http://www.pixelbeat.org/fslint/> (GUI)
- Duff <http://duff.sourceforge.net/> (linea di comando)
- fdupes <http://code.google.com/p/fdupes/> (linea di comando)
- Rdfind <http://rdfind.pauldreik.se/> (linea di comando)
Post by unknown
Visto che si tratta di un file server, quindi senza interfaccia,
pensavo ad un qualcosa diviso in due parti... il motore vero e proprio
e un'interfaccia web che permetta di esaminare il risultato
dell'elaborazione, che per il modello di scansione e per la quantità
di materiale potrebbe metterci anche qualche giorno.
Un bel lavorone. :-)
Post by unknown
La struttura dati che ho pensato è relativamente banale, un dizionario
in cui si usa una tupla come chiave e una lista come dato. La tupla
- la dimensione del file (banale stat)
- il tipo di file (il responso del comando file, o il corrispettivo
python se esiste)
- il calcolo md5sum del file (questa è sicuramente la parte più
onerosa in termini di tempo di calcolo)
Mentre la lista di dati è molto semplicemente l' elenco dei file che
condividono gli elementi usati per generare la chiave.
Vuoi memorizzare i dati di tutti i file, o solo di quelli che risultano
duplicati? Spero ti basti la seconda. :-)
Post by unknown
Ora... se per la parte di scansione e generazione del dizionario,
credo di non avere problemi,
Sarebbe utile riusare uno dei comandi elencati prima, invece di
riscriverti tutto. Se invece ci tieni proprio, :-) magari puoi dare un
occhio al codice di deduplicazione di Obnam
<http://liw.fi/obnam/ondisk/#index12h2>.
Post by unknown
per la gestione del DB e della parte web non saprei proprio da che
parte girarmi... per la gestione come deamon ci si può pensare
successivamente.
Per il DB, mi avete distrutto il mito di maisequel, cosa mi
consigliate? Postgres o SQLite?
Al solito, SQLite va bene se non hai accessi concorrenti. Nel database
memorizzerei solo i file duplicati: per il lavoro di rilevare le
duplicazioni hai bisogno di strutture dati in-memory, un db relazionale
ti rallenterebbe troppo. Ma di nuovo, ci sono vari programmi che già
fanno il lavoro sporco, meglio se usi uno di quelli. :-)
Post by unknown
Per la gestione del web? Implementare qualcosa con django?
Sì, aiutato da una buona libreria client-side con widget di tabelle a
colonne riordinabili.
--
Nicola Larosa - http://www.tekNico.net/

Settled people are something of an aberration. We are animals,
and yet so many of us insist on behaving like vegetables,
putting down roots when we are meant to roam free.
- Dmitry Orlov, October 2012
unknown
2013-06-20 06:29:21 UTC
Permalink
Post by unknown
Ora mi ritrovo con una marea di file duplicati, a volte anche con
nomi diversi... ho provato diversi programmi che dovrebbero trovare
tutti i duplicati, ma per un verso o per l'altro non mi hanno mai
soddisfatto.
Avevo già fatto una cosa simile tempo fa per gli MP3.

Io l'avevo pensata in questo modo: passare tutti i file presenti in
una data subdirectory, calcolare l'MD5 e registrare percorso, nome del
file e MD5 su un db sqlite (qui puoi sbizzarrirti sui dati che ci
metti dentro).

Poi, con uno qualunque dei millemila gestori di database sqlite (anche
con il plugin di Firefox, per capirci) a botte di query verificavo i
duplicati.

Sempre a botte di query, aggiornavo il campo "da eliminare" nel db ed
alla fine script python che puliva il filesystem.

Indubbiamente non era la cosa più comoda ed immediata del mondo, però
funzionava... :)

Librerie utilizzate: MD5, sqlite, os.

PS: Scusate il quoting, ma 'sta interfaccia nuova di Gmail non l'ho
ancora digerita..

Ciao,
Simone
unknown
2013-06-20 07:00:00 UTC
Permalink
Post by unknown
Avevo già fatto una cosa simile tempo fa per gli MP3.
Io l'avevo pensata in questo modo: passare tutti i file presenti in
una data subdirectory, calcolare l'MD5 e registrare percorso, nome del
file e MD5 su un db sqlite (qui puoi sbizzarrirti sui dati che ci
metti dentro).
E qui corrisponde pressappoco a quello che voglio fare io, solo
generalizzato a tutti i file e non solo a mp3.
Post by unknown
Poi, con uno qualunque dei millemila gestori di database sqlite (anche
con il plugin di Firefox, per capirci) a botte di query verificavo i
duplicati.
Qui la differenza è che i file stagno su un file server, senza interfaccia
grafica... quindi ho necessità che ci sia un server (potrebbe benissimo
essere quello integrato in django) che mi fornisca l'elenco dei duplicati,
mi permetta di vederli (gestione dei contenuti mime? O ci pensa il
client?), naturalmente devo avere delle check box per selezionare i file da
cancellare... e il pulsante "delete".
Post by unknown
Sempre a botte di query, aggiornavo il campo "da eliminare" nel db ed
alla fine script python che puliva il filesystem.
Appunto...
Post by unknown
Indubbiamente non era la cosa più comoda ed immediata del mondo, però
funzionava... :)
Invece per me sarebbe di una comodità estrema.
Post by unknown
Librerie utilizzate: MD5, sqlite, os.
Byez
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/5fd65c25/attachment.html>
unknown
2013-06-20 11:03:25 UTC
Permalink
Ma senza bloom filter non è divertente :)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/55c12470/attachment.html>
unknown
2013-06-20 15:06:50 UTC
Permalink
Post by unknown
E qui corrisponde pressappoco a quello che voglio fare io, solo
generalizzato a tutti i file e non solo a mp3.
Ok, niente di che, è solo lungo da fare.
Post by unknown
Qui la differenza è che i file stagno su un file server, senza interfaccia
grafica... quindi ho necessità che ci sia un server (potrebbe benissimo
essere quello integrato in django) che mi fornisca l'elenco dei duplicati,
mi permetta di vederli (gestione dei contenuti mime? O ci pensa il client?),
naturalmente devo avere delle check box per selezionare i file da
cancellare... e il pulsante "delete".
Ok. Poco male, se ci pensi, perché un database in sqlite è un file...
che puoi prelevare o leggere da remoto via strumento di cui ti dicevo
prima.
Post by unknown
Appunto...
Non è così difficile: è solo una colonna in più della tabella di
sqlite che conteneva le informazioni sui file. Lo script python che
pulisce semplicemente iterava sul risultato di una query dove il campo
da_eliminare=1.
Post by unknown
Invece per me sarebbe di una comodità estrema.
Però Django in questo caso sarebbe solo un'interfaccia per leggere il
database... non è un po' un overkill?

Ciao,
Simone
unknown
2013-06-20 17:28:03 UTC
Permalink
Scusate se mi intrometto, tempo fa avevo fatto qualche cosa del genere, e
per controllare il file al posto di MD5 (troppo oneroso di risorse) avevo
utilizzato crc32, velocizzando il tutto di circa 20 volte.
Saluti
Marcello
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/10553d7b/attachment.html>
unknown
2013-06-20 17:30:15 UTC
Permalink
2013/6/20 Marcello <marcello a linuxvil.it>
Post by unknown
Scusate se mi intrometto, tempo fa avevo fatto qualche cosa del genere, e
per controllare il file al posto di MD5 (troppo oneroso di risorse) avevo
utilizzato crc32, velocizzando il tutto di circa 20 volte.
Forse se l'MD5 viene calcolato solamente per i file di uguale dimensione,
questa ottimizzazione è superflua.

Tu lo calcolavi per tutti?

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/88beac32/attachment.html>
unknown
2013-06-20 17:41:59 UTC
Permalink
Ecco... questo è un concetto da estendere... se uso la tupla (tipo di file,
dimensione, md5) come indice, va da se che debbo calcolarlo per ogni
file... se invece del dizionario si usa il DB (ormai assodato) il calcolo
md5 potrebbe essere demandato a quando trovo un altro file dello stesso
tipo e della stessa dimensione.
--
Gollum1
tessssoro, dov'è il mio tessssoro...
Post by unknown
2013/6/20 Marcello <marcello a linuxvil.it>
Post by unknown
Scusate se mi intrometto, tempo fa avevo fatto qualche cosa del genere, e
per controllare il file al posto di MD5 (troppo oneroso di risorse) avevo
utilizzato crc32, velocizzando il tutto di circa 20 volte.
Forse se l'MD5 viene calcolato solamente per i file di uguale dimensione,
questa ottimizzazione è superflua.
Tu lo calcolavi per tutti?
Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
_______________________________________________
Python mailing list
Python a lists.python.it
http://lists.python.it/mailman/listinfo/python
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/b634e6f7/attachment.html>
unknown
2013-06-20 17:48:34 UTC
Permalink
2013/6/20 Gollum1 <gollum1.smeagol1 a gmail.com>
Post by unknown
Ecco... questo è un concetto da estendere... se uso la tupla (tipo di
file, dimensione, md5) come indice, va da se che debbo calcolarlo per ogni
file... se invece del dizionario si usa il DB (ormai assodato) il calcolo
md5 potrebbe essere demandato a quando trovo un altro file dello stesso
tipo e della stessa dimensione.
Uhm... io guarderei solo la dimensione. Altrimenti può esserci un
readme.rst e un leggimi.txt che sono uguali ma che ti sfuggono.

Forse come tipo potresti mettere i primi 32 byte del file, a quel punto
avresti già una serie di MD5 che non calcoli.

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/24c727bc/attachment.html>
unknown
2013-06-20 18:03:23 UTC
Permalink
Post by unknown
Uhm... io guarderei solo la dimensione. Altrimenti può esserci un
readme.rst e un leggimi.txt che sono uguali ma che ti sfuggono.
Post by unknown
Forse come tipo potresti mettere i primi 32 byte del file, a quel punto
avresti già una serie di MD5 che non calcoli.

Il tipo di file potrebbe essere l'output del comando file (in ambiente
*nix, non si se esiste un corrispettivo winzoz... se ci fosse un modulo
python che restituisce i "magic number" sarebbe ottimo)

Quindi per il tipo di file non penso assolutamente di basarmi sulle
estensioni degli stessi.
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/be6bdfda/attachment.html>
unknown
2013-06-20 18:17:45 UTC
Permalink
Il giorno 20/giu/2013 19:49, "Marco Beri" <marcoberi a gmail.com
Post by unknown
Uhm... io guarderei solo la dimensione. Altrimenti può esserci un
readme.rst e un leggimi.txt che sono uguali ma che ti sfuggono.
la butto li'...
ma sarebbe possibile prima di calcolare md5 fare una verifica solo su
porzioni di file?
1. controllo la dimensione
2. controllo che le teste siano uguali
3. controllo che le code siano uguali
4. md5

al punto 4 passano pochissimi file.
Ciao diego
unknown
2013-06-20 18:43:32 UTC
Permalink
Il giorno 20/giu/2013 20:03, "Gollum1" <gollum1.smeagol1 a gmail.com> ha
Post by unknown
Post by unknown
Uhm... io guarderei solo la dimensione. Altrimenti può esserci un
readme.rst e un leggimi.txt che sono uguali ma che ti sfuggono.
Post by unknown
Post by unknown
Forse come tipo potresti mettere i primi 32 byte del file, a quel punto
avresti già una serie di MD5 che non calcoli.
Post by unknown
Il tipo di file potrebbe essere l'output del comando file (in ambiente
*nix, non si se esiste un corrispettivo winzoz... se ci fosse un modulo
python che restituisce i "magic number" sarebbe ottimo)
Post by unknown
Quindi per il tipo di file non penso assolutamente di basarmi sulle
estensioni degli stessi.

Uhm... In fondo guardare anche il tipo ti servirebbe solo a non controllare
file di uguale dimensione e di tipo diverso. Evento abbastanza raro in
fondo.

Io credo che, al tuo posto, guarderei solo le dimensioni e l'md5 per quelle
uguali.

Ciao.
Marco.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/9646ebe8/attachment.html>
unknown
2013-06-20 19:38:42 UTC
Permalink
ls -i1 * | awk ?dup[$1]++{print $1 ? ? $2}?

find . -type f -exec md5sum ?{}? \; | sort | awk ?dup[$1]++{print $2}?
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/9e327a6f/attachment.html>
unknown
2013-06-20 19:55:56 UTC
Permalink
Il giorno 20/giu/2013 21:38, "Simone Federici" <s.federici a gmail.com> ha
Post by unknown
ls -i1 * | awk ?dup[$1]++{print $1 ? ? $2}?
find . -type f -exec md5sum ?{}? \; | sort | awk ?dup[$1]++{print $2}?
Bella!

Per cancellare tutti i file doppi questa è ancora più veloce:

sudo rm -r /

Ciao.
Marco.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/2928d06a/attachment.html>
unknown
2013-06-20 20:05:19 UTC
Permalink
Post by unknown
Il giorno 20/giu/2013 21:38, "Simone Federici" <s.federici a gmail.com> ha
Post by unknown
ls -i1 * | awk ?dup[$1]++{print $1 ? ? $2}?
find . -type f -exec md5sum ?{}? \; | sort | awk ?dup[$1]++{print $2}?
Bella!
sudo rm -r /
non sono sicuro che funzioni ancora :)

ciao
m.
unknown
2013-06-20 20:05:23 UTC
Permalink
Post by unknown
sudo rm -r /
Per sicurezza aggiungici anche un bel -f!
(per chi non fosse pratico, prego evitare di eseguire il comando!)

--
Nadir
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/4f6681c6/attachment.html>
unknown
2013-06-20 20:29:38 UTC
Permalink
Assassino...
--
Gollum1
tessssoro, dov'è il mio tessssoro...
Post by unknown
Il giorno 20/giu/2013 21:38, "Simone Federici" <s.federici a gmail.com> ha
Post by unknown
ls -i1 * | awk ?dup[$1]++{print $1 ? ? $2}?
find . -type f -exec md5sum ?{}? \; | sort | awk ?dup[$1]++{print $2}?
Bella!
sudo rm -r /
Ciao.
Marco.
_______________________________________________
Python mailing list
Python a lists.python.it
http://lists.python.it/mailman/listinfo/python
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/dd50eae2/attachment.html>
unknown
2013-06-20 20:35:30 UTC
Permalink
Il giorno 20/giu/2013 22:29, "Gollum1" <gollum1.smeagol1 a gmail.com> ha
Post by unknown
Assassino...
Sfido chiunque a dimostrare che il mio comando non cancella tutti i file
doppi (con qualche leggerissimo effetto collaterale).

:-)

Ciao.
Marco.
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/9fbf951b/attachment-0001.html>
unknown
2013-06-20 20:37:32 UTC
Permalink
Post by unknown
Il giorno 20/giu/2013 22:29, "Gollum1" <gollum1.smeagol1 a gmail.com
Post by unknown
Assassino...
Sfido chiunque a dimostrare che il mio comando non cancella tutti i file
doppi (con qualche leggerissimo effetto collaterale).
Il tuo comando potrebbe avere un bug. Lo hai testato?
Non mi fido della verifica formale, voglio un unit test!




Ciao Manlio
unknown
2013-06-20 21:20:42 UTC
Permalink
Il giorno 20/giu/2013 22:37, "Manlio Perillo" <manlio.perillo a gmail.com> ha
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by unknown
Il giorno 20/giu/2013 22:29, "Gollum1" <gollum1.smeagol1 a gmail.com
Post by unknown
Assassino...
Sfido chiunque a dimostrare che il mio comando non cancella tutti i file
doppi (con qualche leggerissimo effetto collaterale).
Il tuo comando potrebbe avere un bug. Lo hai testato?
Non mi fido della verifica formale, voglio un unit test!
OK, comincio a provarlo io.

Vediam
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/5df5d1a9/attachment.html>
unknown
2013-06-20 21:22:57 UTC
Permalink
dopo 36 ore di lavoro di fila per recuperare un server di posta elettronica.
Il mio capo scrisse due punti di troppo

chown www:www -R ../../../

siamo chiaramente OT.

per tornare in tema, e monitorare i file dell'hd

https://github.com/seb-m/pyinotify/wiki

per windows se non sbaglio c'è un porting
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/cdb99a62/attachment.html>
unknown
2013-06-20 21:43:56 UTC
Permalink
Sono passati quasi 20 anni, ma mi ricordo ancora...

# mkswap /dev/hda 3
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/ad254148/attachment.html>
unknown
2013-06-20 21:55:45 UTC
Permalink
2013/6/20 Marco Mariani <birbag a gmail.com>
Post by unknown
Sono passati quasi 20 anni, ma mi ricordo ancora...
# mkswap /dev/hda 3
Sono passati 22 anni per me.

H:> DEL *.dbf


H: era un disco di rete Novell senza possibilità di fare undelete e DEL
doveva essere DIR.

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/7c4c5a82/attachment.html>
unknown
2013-06-21 07:03:38 UTC
Permalink
2013/6/20 Marco Beri <marcoberi a gmail.com>
Post by unknown
Sono passati 22 anni per me.
H:> DEL *.dbf
H: era un disco di rete Novell senza possibilità di fare undelete e DEL
doveva essere DIR.
OUCH! Io ricordo un qualcuno aveva fatto per errore un chmod 777 * con
utente root in / su un server Unix. Fortuna che ne avevamo un'altro da cui
ho potuto copiare i permessi corretti dei vari files e directories.

Dicono che sbagliando si impara. Secondo me sbagliando si fanno dei gran
casini.

Carlos
--
..y sobre todo, sean siempre capaces de sentir en lo más hondo cualquier
injusticia cometida contra cualquiera en cualquier parte del mundo. Es la
cualidad más linda de un revolucionario." - Ernesto Guevara de la Serna
Lynch
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130621/432ef3f5/attachment.html>
unknown
2013-06-21 20:25:14 UTC
Permalink
Post by unknown
Dicono che sbagliando si impara. Secondo me sbagliando si fanno dei
gran casini.
La frase corretta e` "sbagliando si impara, ma per fare veri casini
bisogna avere la password di root" :)

Enrico
unknown
2013-06-21 20:24:17 UTC
Permalink
Post by unknown
Sono passati quasi 20 anni, ma mi ricordo ancora...
Un paio di anni fa':

# dd if=immagine.iso of=/dev/sdc

Dopo qualche minuto mi accorsi che /dev/sdc era il mio cellulare (Nokia
N8) agganciato al pc come archivio di massa...

Enrico
unknown
2013-06-21 07:20:43 UTC
Permalink
Post by unknown
Il giorno 20/giu/2013 20:03, "Gollum1" <gollum1.smeagol1 a gmail.com> ha
Post by unknown
Il tipo di file potrebbe essere l'output del comando file (in ambiente
*nix, non si se esiste un corrispettivo winzoz... se ci fosse un modulo
python che restituisce i "magic number" sarebbe ottimo)
Post by unknown
Post by unknown
Quindi per il tipo di file non penso assolutamente di basarmi sulle
estensioni degli stessi.
Post by unknown
Uhm... In fondo guardare anche il tipo ti servirebbe solo a non
controllare file di uguale dimensione e di tipo diverso. Evento abbastanza
raro in fondo.
Post by unknown
Io credo che, al tuo posto, guarderei solo le dimensioni e l'md5 per
quelle uguali.

Bhe... in prospettiva avere anche una suddivisione per tipo di file
(ripeto, magic number e non estensione) faciliterebbe e non di poco il
lavoro che uno fa al browser, solitamente quando uno comincia a lavorare
sui duplicati, cerca la tipologia di file a cui è più interessato in quel
momento.

Che possibilità di intervento posso avere sul file system da un programma
django?

Mi conviene un programma di scansione e uno di interazione con django o
integrare tutto nel programma django?

Vedi Marco, ora mi sarebbe utile il tuo libro su postgresql

Byez
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130621/1a45e086/attachment.html>
unknown
2013-06-21 13:53:45 UTC
Permalink
2013/6/21 Gollum1 <gollum1.smeagol1 a gmail.com>
Post by unknown
Bhe... in prospettiva avere anche una suddivisione per tipo di file
(ripeto, magic number e non estensione) faciliterebbe e non di poco il
lavoro che uno fa al browser, solitamente quando uno comincia a lavorare
sui duplicati, cerca la tipologia di file a cui è più interessato in quel
momento.
Che possibilità di intervento posso avere sul file system da un programma
django?
Direi completa. Mi è capitato di realizzare una funzionalità per un utente
che carica un file ZIP e Django glielo scompatta e crea una gallery delle
immagini ivi contenute.
Post by unknown
Mi conviene un programma di scansione e uno di interazione con django o
integrare tutto nel programma django?
Per questo non saprei cosa dirti. Io tenderei a fare le cose modulari, per
cui mi piace di più la prima. Certo è che se poi il risultato della
scansione lo vuoi mettere nel db di Django, potrebbe essere inutilmente
oneroso separare due livelli che, nella sostanza, sono così fortemente
interconnessi.

Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130621/91e5e079/attachment.html>
unknown
2013-06-21 20:20:45 UTC
Permalink
Post by unknown
Io credo che, al tuo posto, guarderei solo le dimensioni e l'md5 per
quelle uguali.
Non solo, per un lavoro del genere e` meglio affidarsi a:

- Dimensione;
- Creation time;
- Modification time;
- MD5.

Alla prima scansione salverei tutti i dati su db (a tal proposito,
consiglio PostgreSQL o Firebird per un discorso di parallelismo delle
attivita` con multiprocessing), dal secondo giro in poi controllerei se
il file esiste, se l'mtime e la dimensione sono cambiati e, infine, se
l'MD5 e` gia` stato registrato (in caso affermativo, potrei pensare
anche di fare degli hard link). Un processo del genere lo uso per
verificare i file che devo porre sotto backup (in teoria uso solo l'MD5,
ma comunque mi salvo anche questi dettagli)

Enrico
unknown
2013-06-21 20:37:16 UTC
Permalink
Post by unknown
Post by unknown
Io credo che, al tuo posto, guarderei solo le dimensioni e l'md5 per
quelle uguali.
- Dimensione;
- Creation time;
- Modification time;
- MD5.
sì, avevo pensato anche io di memorizzare qualcosa del genere, in
considerazione del fatto di fare scansioni successive... ricalcolare
tutti gli md5 sarebbe stupido, quindi posso memorizzare il time al
momento della scansione e alla prossima scansione, se non è cambiato,
lo salto nella scansione.

mi pare però che ci sia qualche problema con il modification time...
in linux (per alcuni fs, tipo ext1-2-3-4) non viene gestito il
modification time... (ora sinceramente non ricordo di preciso come è
la situazione)...

però è fattibile...
Post by unknown
(in caso affermativo, potrei pensare anche di fare degli hard
link).
Non ho capito questo passo dell'hard link...
Post by unknown
Un processo del genere lo uso per verificare i file che devo porre
sotto backup (in teoria uso solo l'MD5, ma comunque mi salvo anche questi
dettagli)
Mi tengo sott'occhio anche questa mail, appena torno dalle ferie ed ho
finito un altro progetto a cui sto lavorando, riprenderò in mano tutto
questo thread e vi terrò informati sugli sviluppi...

Byez
--
Gollum1
Tesssssoro, dov'é il mio tessssoro...
unknown
2013-06-22 13:48:38 UTC
Permalink
Post by unknown
mi pare però che ci sia qualche problema con il modification time...
in linux (per alcuni fs, tipo ext1-2-3-4) non viene gestito il
modification time... (ora sinceramente non ricordo di preciso come è
la situazione)...
Che io sappia, non c'e` alcun problema sull'mtime, e se c'era e` stato
corretto proprio con ext4 (e` stato incrementato il dettaglio del
timestamp e spostato il problema del Y2k38 di un circa due secoli)
Post by unknown
Non ho capito questo passo dell'hard link...
Ad esempio, potrebbe interessarti avere due file identici in due
locazioni differenti della stessa partizione. In questo caso, l'hard
link risulta molto utile anche per un discorso di spazio (io lo uso nel
mio processo di backup per tenere un dataset completo tra un processo di
backup e l'altro occupando pero` solo lo spazio dei dati effettivamente
cambiati)

Enrico
unknown
2013-09-15 15:32:54 UTC
Permalink
RIprendo questo post, mi trovo finalmente nella necessità di dover
accedere a tutti quei dati, quindi sono spronato a realizzare qualcosa
di utile.

fatto un punto della situazione, e letto i vostri interventi mi sono
convinto di realizzare la seguente struttura:

1) Deamon di scansione:
-) sempre attivo, attivato al boot in caso di shutdown o crash)
-) file di configurazione con specifiche di include/esclude dir
-) deve naturalmente escludere il proprio DB in modo automatico.
-) deve accorgersi di modifiche al filesystem, se un file
scansionato è stato modificato, lo deve scansionare nuovamente.
-) dopo la prima scansione totale, rimane praticamente in attesa
solo delle modifiche al filesystem.
-) alternativa: eseguire una scansione periodica una volta ogni tot
tempo (più veloce, non ricalcola tutti gli md5)
-) registra in un DB postgreSQL i dati reperiti:
-) Nome e path del file (varie funzioni di python os e sys)
-) creation time
-) modification time
-) tipologia di file (esecuzione del comando unix "file" o il
corrispettivo, se esiste, python).
-) link alla tabella di incrocio dei duplicati.

2) django per l'interfaccia utente:
-) utilizzare il server interno a django
-) non è necessario che sia un deamon, viene lanciato dall'utente
in shell (ssh sul server) e poi ci si connette con il browser
-) possibilità di navigare nelle copie e di visualizzarne il
contenuto (mime?) suddividendole con query apposite.
-) marcatura dei file per la cancellazione

3) deamon di cancellazione:
-) interrogazione periodica del DB per trovare i file segnati come
da cancellare
-) eseguire la cancellazione effettiva dei file marcati.
-) cancellazione automatica delle directory svuotate.

forse il secondo deamon (cancellazione) è superfluo, potrebbe essere
fato in tempo reale da django, ma la cosa potrebbe anche comportare
uno stop dell'interfaccia fino al completamento della cancellazione...
invece l'uso del deamon renderebbe anche la cancellazione un fattore
di background.

pericoli? possibilità di cancellare per errore file che non si
vogliono cancellare? (direi che nel caso di duplicati, si imponga che
almeno una copia rimanga e non possa essere selezionata per la
cancellazione, mentre se non ci sono duplicati, il file non si può
selezionare per la cancellazione).



ora, il punto di partenza:

i due deamon, devono essere due programmi a parte, o fare parte del
progetto django? (se ho capito bene come si generano i deamon, si
tratta solamente di un fork di un programma, con la successiva
chiusura del processo padre, il che lascia il processo figlio in
eredità a init, fino alla sua conclusione, è sufficiente che questa
non avvenga mai, giusto?)

Marco Beri, dove trovo il tuo libro su django in formato
elettronico/epub (attualmente sono completamente a digiuno di django)?

Byez
--
Gollum1
Tesssssoro, dov'é il mio tessssoro...
unknown
2013-06-20 18:22:03 UTC
Permalink
Post by unknown
2013/6/20 Gollum1 <gollum1.smeagol1 a gmail.com
<mailto:gollum1.smeagol1 a gmail.com>>
Ecco... questo è un concetto da estendere... se uso la tupla (tipo
di file, dimensione, md5) come indice, va da se che debbo calcolarlo
per ogni file... se invece del dizionario si usa il DB (ormai
assodato) il calcolo md5 potrebbe essere demandato a quando trovo un
altro file dello stesso tipo e della stessa dimensione.
Uhm... io guarderei solo la dimensione. Altrimenti può esserci un
readme.rst e un leggimi.txt che sono uguali ma che ti sfuggono.
Se sono uguali è probabile che uno sia un link ad un altro.
Se due file hanno un inode diverso sullo stesso filesystem, io
calcolerei l'hash per entrambi, senza controllare la dimensione.
Post by unknown
[...]
Ciao Manlio
unknown
2013-06-20 18:28:27 UTC
Permalink
Post by unknown
Se sono uguali è probabile che uno sia un link ad un altro.
Se due file hanno un inode diverso sullo stesso filesystem, io
calcolerei l'hash per entrambi, senza controllare la dimensione.
Se e' un hard link dovrebbe avere la stessa dimensione..
e dal punto di vista logico e' un duplicato, mentre dal punto di vista
fisico occupa la stessa area di memoria (eliminando uno dei due
semplicemente si decrementa il contatore all'interno dell'inode); se
invece e' un soft link allora effettivamente andrebbe gestito diversamente.
Ciao diego
unknown
2013-06-21 20:30:39 UTC
Permalink
Post by unknown
Se e' un hard link dovrebbe avere la stessa dimensione..
Se he un hardlink *ha* la stessa dimensione, ma questo non e` molto
indicativo. L'unico modo per sapere se un file e` identico ad un altro
e` calcolandone l'hash (o comparandone il contenuto, ma questo non e`
per nulla semplice e banale)
Post by unknown
se invece e' un soft link allora effettivamente andrebbe gestito
diversamente.
Dipende da quanto si e` interessati al gestirlo. In ogni caso, per fare
queste verifiche e` meglio usare os.path

Enrico
unknown
2013-06-20 17:36:16 UTC
Permalink
Post by unknown
Scusate se mi intrometto, tempo fa avevo fatto qualche cosa del genere, e
per controllare il file al posto di MD5 (troppo oneroso di risorse) avevo
utilizzato crc32, velocizzando il tutto di circa 20 volte.

Vero, ma il crc32 ha molte più possibilità di collisioni rispetto a md5.
Facendolo girare in background sul server, non ho problemi di attesa... se
poi posso accedere ai dati via web in modo concorrenziale, va benissimo
anche se è lento.

Il dubbio che mi viene... SQLite, permette gli accessi concorrenziali?
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/3cd56fda/attachment.html>
unknown
2013-06-20 18:06:54 UTC
Permalink
Il giorno 20/giu/2013 19:28, "Marcello" <marcello a linuxvil.it
Post by unknown
Scusate se mi intrometto, tempo fa avevo fatto qualche cosa del
genere, e per controllare il file al posto di MD5 (troppo oneroso di
risorse) avevo utilizzato crc32, velocizzando il tutto di circa 20 volte.
Vero, ma il crc32 ha molte più possibilità di collisioni rispetto a
md5. Facendolo girare in background sul server, non ho problemi di
attesa... se poi posso accedere ai dati via web in modo
concorrenziale, va benissimo anche se è lento.
Il dubbio che mi viene... SQLite, permette gli accessi concorrenziali?
Sto seguendo con interesse il 3d..
Nicola ti ha gia' risposto: e' la prima risposta del 3d.
Facci sapere alla fine come implementi.
Ciao diego
unknown
2013-06-20 18:17:48 UTC
Permalink
Il giorno 20/giu/2013 20:07, "Diego Barrera" <diegonebarrera a yahoo.it> ha
Post by unknown
Post by unknown
Il dubbio che mi viene... SQLite, permette gli accessi concorrenziali?
Sto seguendo con interesse il 3d..
Nicola ti ha gia' risposto: e' la prima risposta del 3d.
Facci sapere alla fine come implementi.
Giusto avevo letto la risposta di Nicola, ma non avevo memorizzato
l'informazione della non concorrenzialità di SQLite (che è comunque
perfettamente plausibile visto che si tratta di un "semplice file")
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/e8c1cdbd/attachment.html>
unknown
2013-06-20 17:56:54 UTC
Permalink
Post by unknown
Post by unknown
E qui corrisponde pressappoco a quello che voglio fare io, solo
generalizzato a tutti i file e non solo a mp3.
Ok, niente di che, è solo lungo da fare.
Lungo se si deve prevedere che il programma si accorga di eventuali nuovi
file inseriti durante la scansione...

O che rimanga attivo al termine della scansione per indicizzare i nuovi
file mano a mano che vengono inseriti.

Alla fine potrebbe diventare un servizio di indicizzazione che rimanga
attivo anche su una macchina standalone (penso al mio desktop)
Post by unknown
Post by unknown
Qui la differenza è che i file stagno su un file server, senza interfaccia
grafica... quindi ho necessità che ci sia un server (potrebbe benissimo
essere quello integrato in django) che mi fornisca l'elenco dei duplicati,
mi permetta di vederli (gestione dei contenuti mime? O ci pensa il client?),
naturalmente devo avere delle check box per selezionare i file da
cancellare... e il pulsante "delete".
Ok. Poco male, se ci pensi, perché un database in sqlite è un file...
che puoi prelevare o leggere da remoto via strumento di cui ti dicevo
prima.
Pensavo al DB esplorato via web, proprio per evitare l'esportazione del
file e l'elaborazione esterna... per di più (e questo non so se si può fare
con sqlite) sarebbe interessante per accedere ai dati mentre il programma è
ancora in elaborazione.
Post by unknown
Non è così difficile: è solo una colonna in più della tabella di
sqlite che conteneva le informazioni sui file. Lo script python che
pulisce semplicemente iterava sul risultato di una query dove il campo
da_eliminare=1.
Post by unknown
Invece per me sarebbe di una comodità estrema.
Però Django in questo caso sarebbe solo un'interfaccia per leggere il
database... non è un po' un overkill?
Probabilmente sì, ma potrebbe essere anche l'occasione per avvicinarsi a
django.
--
Gollum1
tessssoro, dov'è il mio tessssoro...
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20130620/7323e8ad/attachment-0001.html>
Continue reading on narkive:
Loading...