C'è un momento in cui un file "non esiste" durante una rinomina?

Abbiamo un programma Java di terze parti in black-box che prende i file di input da una posizione e crea PDF. Mette un file manifest nella stessa posizione ogni volta per ogni input che ci richiede di alimentare il file in modo controllato. Il manifest (o .xen/.que) esiste ancora? Non alimentare un file di input.C'è un momento in cui un file "non esiste" durante una rinomina?

Stiamo ottenendo MOLTO rari (uno su decine di migliaia di file) istanze del nostro script di feed che non trovano nulla, alimentano un file e l'errore risultante quando il manifest viene sovrascritto e le cose non corrispondono. Ho scritto uno script perl che non fa altro che stampare il tempo fino a 100 millesimi, inserire qualsiasi cosa nella directory che ci interessa e stamparlo. Sotto puoi vedere .xen e .que file dove .xen è l'input e .que è una versione rinominata di esso per indicare l'elaborazione.

La mia domanda è questa: come è possibile la mancanza di file a 94.26493? Il sistema operativo nasconde un file mentre sta rinominando? Stiamo riscontrando il nostro problema quando il programma di feed cerca i file in quel momento, quindi il mio hack pianificato è controllare i file due volte; si spera abbastanza lento da catturare entrambe le estremità del rinominare. Dovrei anche sottolineare che una volta che 2 file appaiono su una riga, è qui che il programma di alimentazione ha inserito un altro file. Non è lo stesso file di prima della rinomina.

1421417394.26392/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen 
1421417394.26416/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen 
1421417394.26442/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen 
1421417394.26468/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen 
1421417394.26493 
1421417394.26907/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen.que_142_1421417394265 
1421417394.27426/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen /gpfs/fsdd/projects/corr_esch/corr_esch.d.xen.que_142_1421417394265 
1421417394.27456/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen /gpfs/fsdd/projects/corr_esch/corr_esch.d.xen.que_142_1421417394265 
1421417394.27486/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen /gpfs/fsdd/projects/corr_esch/corr_esch.d.xen.que_142_1421417394265 
1421417394.27528/gpfs/fsdd/projects/corr_esch/corr_esch.d.xen /gpfs/fsdd/projects/corr_esch/corr_esch.d.xen.que_142_1421417394265

fonte

2015-01-16 pete1450

Per quanto ne so, [rinominare è un'operazione atomica su sistemi POSIX] (http://stackoverflow.com/questions/167414/is-an-atomic-file-rename-with-overwrite-possible-on -windows), quindi penso che il file "esisterebbe" sia prima che dopo l'operazione di rinomina. Le operazioni con i file di Windows sono * non * generalmente atomiche a meno che non venga utilizzato [Transactional NTFS] (http://msdn.microsoft.com/en-us/library/windows/desktop/bb968806%28v=vs.85%29.aspx), ma dal momento che questa domanda è contrassegnata come "unix", suppongo che non sia pertinente. – GoBusto

Corretto, in particolare AIX – pete1450

È possibile includere le parti rilevanti del programma perl? –

L'attuale guarantee in POSIX è che se si rinomina a-b e b esiste già, non ci sarà nessun punto nel tempo durante la ridenominazione quando b non esiste. Si riferirà allo b o al nuovo b precedentemente chiamato a.

Se b non esiste già (il che sembra essere il caso nell'esempio), la garanzia non è valida. È possibile che esista un momento in cui né a né esiste (dipende da come funziona il particolare file system). È anche possibile che esista un momento in cui sono presenti sia a sia b (e si riferiscono allo stesso file).

La soluzione proposta di controllo due volte con un breve ritardo è probabilmente l'approccio più semplice.

fonte

2015-01-16 15:33:37 cjm

Speravo di essermi sbagliato. Ho letto il documento che hai fornito e giunto alla stessa conclusione. Grazie per la conferma. – pete1450

È atomico se è lo stesso file system (stesso punto di montaggio). Se si attraversano i file system, allora suppongo che ci sia un lasso di tempo in cui entrambi esistono ma che potrebbero variare tra i sistemi e l'implementazione. Inoltre, tutti i commenti riguardano effettivamente la chiamata di sistema di rinomina che Java può o non può scegliere di utilizzare. E vedo anche "gpfs" nel percorso che è un file system remoto, quindi suggerirei che tutte le scommesse siano state disattivate. :-) – pedz

@pedz, 'rename' non funziona necessariamente su file system (c'è un errore' EXDEV' definito per i sistemi operativi che non supportano questo). Inoltre, la garanzia non ha mai detto nulla su quando 'a' esiste o non esiste, solo che' b' esisterà sempre. – cjm

C'è un momento in cui un file "non esiste" durante una rinomina?

risposta

Problemi correlati