Salve,

Un po 'di uno stupido questione. Sorry folks.

Supponiamo che ho questo file che viene aggiornato a intervalli irregolari (pochi secondi, a pochi minuti, chi lo sa) da parte di un processo di sfondo.

I 'VI'Questo file con l'intenzione di modificare, in modo tale che si apre un temp copia come di consueto / tmp/720cwhatever

Ora supponiamo che, mentre ho aperto questo file, il suo aggiornamento più volte da sfondo processo.

Faccio mie modifiche, salvare, uscire.

Cosa succede al aggiornamenti che sono state fatte da sfondo il processo nel corso del tempo ho avuto il file aperto?


Come faccio a mitigare questo?
(purtroppo, l'arresto del processo di sfondo non è una opzione).


Il file è anche abbastanza grande (circa 40MB), in modo che si VI pochi secondi per caricare il sistema, a salvare ecc ....


Unix è ksh.
OS è SunOS.

Hope you guys può aiutare! - Grazie in anticipo!

Gli aggiornamenti da sfondo processo non sono perso, la domanda è: che cosa succede quando si sta per fare "salva e chiudere" - vi sarà chiesto di messaggio che il file originale è cambiato: non si desidera salvare comunque?
L'altra cosa è quando qualcuno sta cercando di VI lo stesso file aperto da voi - egli verrà visualizzato un messaggio:

, ma suppongo che si intende di file di log di grandi dimensioni, in modo che la soluzione può variare a seconda di cosa esattamente si vuole fare.

Percy, sysgate notare come, la tua soluzione dipenderà su cosa
che si desidera aggiornare il file.
E 'veramente necessario "VI"Il file?
Potrebbe essere scritta una shell di fare gli aggiornamenti che si desidera?

OK cheers guys!

Un po 'più di informazioni:

Che cosa voglio fare è questa:

Si tratta di un grande file, piena di nomi di file e un hashcode per ogni file.
ogni riga del file è
il nome del file, data, hashcode
il nome del file, data, hashcode
...

In ogni caso, un file in modo entra in un server, riceve un hashcode che viene poi messo in questa grande miniera di file di log, e poi il file viene trasformato.

Se il file è inviato nuovamente al server, la sua hashcode è controllato e, se esiste (ad esempio, il mio processo ha già affrontato) si occupa con il file appropriato.

Vengo scollarsi, quando ho bisogno di rielaborare lo stesso file di nuovo - così ho bisogno di modificare il file di log di grandi dimensioni e rimuovere la voce (tutta la linea - il nome, la data, hashcode) in modo che possa di nuovo attraverso i mangimi.


Scrivi una sh per affrontare questo? - Non è sicuro - la sua una di quelle in cui si verifica spesso, ma spesso non basta a giustificare un sh .... ma la sua qualcosa Penso potrebbe esaminare.


Un altra cosa:

Supponiamo che due persone sudos ad un utente (lo stesso utente), prima, e poi le modifiche del file - non si ottiene il messaggio sul file cambiando quando si salva / uscire a destra? - Almeno questo è quello che sembra accadere qui in Bizarro mondo ...

Percy,
Ecco una possibile soluzione:
1) Rinominare il "work_file" ad una "tmp_file" immediatamente e creare un
nuovo "work_file" in modo che le nuove registrazioni, possono continuare ad essere aggiunto ad essa.
2) "VI"Il" tmp_file "e fare tutte le modifiche desiderate.

2.a) Quando si è finito con le modifiche in merito alla "tmp_file",
non chiudere ancora.

2.b) Vai alla fine del "tmp_file" e nella riga di comando digitare:
Questo permette di leggere la "work_file" interamente e luogo dopo l'ultima riga
di "tmp_file".

2.c) Scrivere e chiudere il "tmp_file".
Come si dice il file è molto grande, se si tenta di salvare l'area di lavoro
come "work_file", esso può richiedere molto tempo e utilizzo di un lotto di memoria
e lo spazio su disco.

3) Immediatamente rinominare "tmp_file" torna a "work_file".
Vedi se questo potrebbe lavorare per voi.

La ringrazio per questo.

C'è ancora la possibilità di lievi mancanti aggiunte al file di log tra i passaggi 2 quater e 3 - e principalmente a causa della sua rapida come posso tipo "mv file file2" - in un panico, probabilmente più tempo che colpisce il fatto che il backspace comandi digitando correttamente.

La sua migliore catcher sicuramente uno dei commenti che la soluzione che avevo in mente - in modo molto, grazie!