2013-09-27 11 views
9

Ho un problema rapido con la funzione python os.path.getmtime(). Ho osservato alcuni comportamenti strani. Sto lavorando a un'app Web che controlla periodicamente per vedere se un certo file è stato modificato e decide se aggiornarlo in base a ciò.python os.path.getmtime() ora non cambia

Nella mia riga di comando python locale, quando cambio il file e chiamo os.path.getmtime(file_name) il valore restituito da mtime è stato modificato per riflettere la modifica nel file.

Tuttavia, quando chiamo os.path.getmtime() nella mia app Web, il valore restituito prima e dopo la modifica è lo stesso. Ho fatto qualche ricerca online e ho trovato alcune cose per suggerire che il modulo os deve essere ricaricato per la modifica del file da registrare. Quindi, nella mia app Web ho ricaricato il modulo os, ma mtime non riflette ancora le modifiche al file. Qualcun altro ha già riscontrato questo problema o conosce una soluzione? Ho incluso un frammento di codice di seguito dalla webapp:

import os 

def function_name(): 
    reload(os) 
    file_path = '/dir/lib/some_file.js' 

    try: 
     mtime = os.path.getmtime(file_path) 
    except os.error: 
     pass 

    return mtime 
+1

No, ricaricare il modulo 'os' ha ** ** nulla a che fare con questo. –

+0

Aah, ok. Sì, ho letto in uno dei documenti python che 'os.environ' è impostato solo quando il modulo os è caricato e ho pensato che potesse avere qualcosa a che fare con quello. –

+1

'os.path.getmtime()' non memorizza nella cache nulla. Restituisce semplicemente 'os.stat (filename) .st_mtime'. 'os.stat()' non memorizza nulla nella cache, chiama semplicemente nella libreria C, che chiede al sistema operativo per tali informazioni. –

risposta

0

Forse si potrebbe provare a ottenere statistiche generali sul file oltre mtime come le dimensioni.

È la dimensione/mtime prevista del file prima e dopo la modifica sul server (ad esempio quando si visualizza ls -l in una finestra di terminale) uguale o diversa.

Se le statistiche quando si utilizzano tali strumenti da riga di comando sono uguali, è possibile che il file non venga modificato dove si pensa.

Se la dimensione/mtime è diverso forse usare

os.stat(filename) 

e vedere se si dà uno qualsiasi dei valori corretti.

1

io non ho abbastanza reputazione per aggiungere questo come un commento ...

Non è chiaro come si sta testando, fa una singola pagina del vostro web app

  • stampa mtime
  • aggiornamento del file di
  • mtime stampa

O

  • semplicemente stampa mtime

Se il processo di test web-app è

  • richiesta di test mtime pagina
  • aggiornare manualmente il file
  • richiesta di una pagina di prova mtime
  • nota che mtime è uguale su entrambe le visualizzazioni di pagina

la mia prima ipotesi è il client Web, il proxy o il caching del server.

1

L'ho incontrato oggi e ho trovato questa domanda, quindi ho pensato di documentarlo qui.Il mio caso era un test unitario, quindi potrebbe essere leggermente diverso poiché riguarda tempi più piccoli di un test manuale.

La data di modifica è limitata dal file system. Se si controlla il tempo di modifica, quindi scrivere una piccola quantità di dati, quindi controllare nuovamente l'ora di modifica, i due timestamp potrebbero essere esattamente uguali. Saranno uguali se il tempo tra il controllo del primo timbro temporale e la fine della scrittura è inferiore alla risoluzione temporale.

Alcune statistiche sulla risoluzione temporale di vari file comuni sistemi:

  • FAT32: 2s
  • ext3: 1s
  • exFAT: 10ms
  • NTFS: 100ns
  • ext4: 1ns

Si può aspettare sistemi a usare il grasso, e hanno a ti incorporato mi risoluzione di 2 secondi. I vecchi sistemi Windows saranno nell'intervallo di 2 secondi. I sistemi Windows più recenti avranno 100ns o 10ms. I vecchi sistemi UNIX avranno spesso 1s. I nuovi sistemi UNIX avranno una risoluzione di 1ns.

Se <time for time stamp check> + <time for file write> è inferiore alla risoluzione di tempo, il file potrebbe apparire come se non modificati.

vedo queste possibili soluzioni:

  • Includere un ora di modifica più accurata nell'intestazione del file che si sta scrivendo. Il writer di file può anche verificare se il file esiste già prima di scrivere e incrementare il tempo di modifica del nanosecondo di almeno 1 per garantire che si aggiorni (al costo della precisione del timestamp).
  • Conservare altrove quante volte ciascun file è stato modificato. Usa questo numero per vedere se è stato modificato dall'ultimo controllo. Si noti che probabilmente non è possibile scrivere atomicamente il file e aggiornare insieme il conteggio delle modifiche.
  • Forse alcuni trucchi possono essere concepiti con posti letto, in modo che il tempo che intercorre tra il primo controllo timestamp e il file di scrittura è sempre almeno la risoluzione minima di tempo. Ciò dipenderebbe in gran parte dal tipo di installazione e bloccherebbe il thread.