2016-05-11 21 views
5

Nella mia applicazione leggo file usando seguente metodo,Il tempo di accesso all'ultimo file e l'ultima volta modificata in java?

public void readFIleData(String path) { 
    BufferedReader br = null; 
    try { 
     String sCurrentLine; 
     br = new BufferedReader(new FileReader(path)); 
     while ((sCurrentLine = br.readLine()) != null) { 
      System.out.println("Data : "+sCurrentLine); 
     } 
    } catch (IOException e) { 
     e.printStackTrace(); 
    } finally { 
     try { 
      if (br != null)br.close(); 
     } catch (IOException ex) { 
      ex.printStackTrace(); 
     } 
    } 
} 

Inoltre ottengo ora di accesso e l'ultima volta modificata del file utilizzando seguente metodo,

public void getFIleInfo(String path) { 
    Path file = Paths.get(path); 
    try { 
     BasicFileAttributes attrs = Files.readAttributes(file, BasicFileAttributes.class); 
     FileTime accessTime = attrs.lastAccessTime(); 
     System.out.println("accessTime : "+accessTime.toMillis()); 
     FileTime modifiedTime = attrs.lastModifiedTime(); 
     System.out.println("modifiedTime : "+modifiedTime.toMillis()); 
    } catch (IOException e) { 
     e.printStackTrace(); 
    } 
} 

ho corse metodi di cui sopra in ordine seguente ,

1-> getFIleInfo() 
2-> readFIleData() 
3-> getFIleInfo() 

mi ha fatto seguito come output,

accessTime : 1462943491685 
modifiedTime : 1462943925846 
Data : erteuyuittdgfdfghjkhw5643rtrr66664fdghf 
accessTime : 1462943491685 
modifiedTime : 1462943925846 

Ecco gli orari di uscita in formato stringa,

accessTime : 2016-05-11T05:11:31.685881Z 
modifiedTime : 2016-05-11T07:39:28.237884Z 
Data : erteuyuittdgfdfghjkhw5643rtrr66LE229F1HBQ664fdghf 
accessTime : 2016-05-11T05:11:31.685881Z 
modifiedTime : 2016-05-11T07:39:28.237884Z 

Ho un dubbio su questa uscita perché il tempo di accesso rimane la stessa di prima lettura dei dati del file. Qualcuno può spiegarmi che cosa è in realtà significato per l'ultimo accesso e l'ultima volta in java?

+0

[Questa potrebbe essere la ragione] (http://superuser.com/questions/251263/the-last-access-date-is-not-changed-even-after-reading-the-file-on-windows -7). In un'altra nota, su quale sistema operativo si sta eseguendo? Potrebbe non essere colpa di Javas, ma invece il SO non lo aggiorna correttamente – Draken

+0

Win8.1 64bit qui e posso replicare lo stesso. Interessante. –

+4

Java non fa nulla da solo: richiede solo valori al file system sottostante. Per sicurezza, basta creare un file di testo, guardare * con gli strumenti os o file system * al momento dell'accesso ('ls -atime' su Unix-like, o explorer su Windows), attendere uno o due minuti, visualizzare il file e guardare ancora una volta il tempo di accesso. Se nulla è cambiato, il file system sottostante è colpevole. –

risposta

2

Per prima cosa, concentriamoci su cosa significano queste cose.

Accesso - l'ultima volta che il file è stato letto, ovvero l'ultima volta che è stato effettuato l'accesso ai dati del file.

Modifica - l'ultima volta che il file è stato modificato (il contenuto è stato modificato), ovvero l'ora in cui i dati del file sono stati modificati per l'ultima volta.

Modifica - l'ultima volta che i metadati del file sono stati modificati (ad esempio permessi), cioè, quando lo stato del file è stato modificato l'ultima volta.

Modifica. Il tempo di accesso IS cambia. Suggerisco di utilizzare Thread.sleep(100) o qualcosa del genere e quindi vedere se il problema persiste. Se lo fa, il colpevole dovrebbe essere il sistema operativo in esecuzione poiché Java legge semplicemente dal filesystem. I commenti di @Serge Ballesta dovrebbero fornire informazioni su Windows NTFS con un'opzione per disabilitare la scrittura di tutte le modifiche apportate agli attributi del file sul disco rigido per motivi di prestazioni. In realtà c'è di più in questo.

Da [docs],

NTFS ritarda gli aggiornamenti l'ultima volta di accesso per un file fino ad un'ora dopo l'ultimo accesso. NTFS consente inoltre di disabilitare gli aggiornamenti dell'ultimo accesso. L'ultima ora di accesso non è aggiornata sui volumi NTFS per impostazione predefinita.

Di seguito sono riportati alcuni dati dall'esecuzione dello script su mac os x.

calling getFileInfo() at: 11.4.2016 3:13:08:738 
    accessTime : 11.4.2016 3:12:53:0 
    modifiedTime : 29.10.2015 1:49:14:0 
-------------------- 
sleeping for 100ms 
-------------------- 
calling readFIleData() at: 11.4.2016 3:13:08:873 
-------------------- 
sleeping for 100ms 
-------------------- 
re-calling getFileInfo() at: 11.4.2016 3:13:08:977 
    accessTime : 11.4.2016 3:13:08:0 <---- READING FILE CHANGES ACCESS TIME 
    modifiedTime : 29.10.2015 1:49:14:0 
-------------------- 
sleeping for 100ms 
-------------------- 
re-calling getFileInfo() at: 11.4.2016 3:13:09:81 
    accessTime : 11.4.2016 3:13:08:0 <---- READING FILE ATTRIBUTES DOES NOT CHANGE ACCESS TIME 
    modifiedTime : 29.10.2015 1:49:14:0 


Per migliorare la chiarezza, è possibile convertire i millisecondi che avete, a qualcosa di più leggibile. Il seguente frammento di codice verrà elaborato in merito.

long accessTimeSinceEpoch = Files.readAttributes(file, BasicFileAttributes.class).lastAccessTime().toMillis(); 

Calendar calendar = Calendar.getInstance(); 
calendar.setTimeInMillis(accessTimeSinceEpoch); 

int mYear = calendar.get(Calendar.YEAR); 
int mMonth = calendar.get(Calendar.MONTH); 
int mDay = calendar.get(Calendar.DAY_OF_MONTH); 

int mHour = calendar.get(Calendar.HOUR); 
int mMin = calendar.get(Calendar.MINUTE); 
int mSec = calendar.get(Calendar.SECOND); 
int mMilisec = calendar.get(Calendar.MILLISECOND); 
String st = mDay + "." + mMonth + "." + mYear + " " + mHour + ":" + mMin + ":" + mSec + ":" + mMilisec; 
+1

Questo non risponde affatto alla domanda. Non sta chiedendo la conversione di millis. Si sta chiedendo perché la chiamata da leggere non influisce sull'ultimo accesso. –

+0

@RichardEriksson Mi scuso per la mancanza di chiarezza. Mi aspettavo che la prima parte della risposta avesse risposto a quella parte della domanda. –

+0

@RichardEriksson Effettua una modifica –

0

Se osservate l'api avete questo.

Se il file system non supporta una marca temporale per indicare l'ora dell'ultimo accesso, allora questo metodo restituisce un valore predefinito specifica implementazione, in genere il last-modified-time o un FileTime che rappresenta l'epoca (1970-1901 -01T00: 00: 00Z).

Sembra proprio che il "problema" sia correlato al file system e al sistema operativo. Non penso che il tuo codice abbia qualcosa di sbagliato in questo.

Ad esempio, per un windows operating system, l'opzione NtfsDisableLastAccessUpdate è stata attivata per impostazione predefinita in Vista e Windows 7, ma è possibile disattivarla utilizzando la seguente riga di comando:

fsutil behavior set disablelastaccess 0 

Come ho detto nel commento la tua domanda sono riuscito a risolvere questo problema in Windows in una macchina reale, ma non in una virtuale. Se si sta ancora lottando con questo problema allora emettere questo comando prima di qualsiasi cosa per vedere che cosa sta succedendo con il Registro di sistema:

fsutil behavior query disablelastaccess 

Su un ultima nota, non ho dovuto riavviare Windows o Intellij (dove ho incontrato il mio test). I risultati sono stati immediati e ho potuto vedere che per il valore 1 il timestamp per l'ultimo accesso non cambia e per il valore 0 lo fa.