---

Hejsa,

Det sker jeg har brug for atomart at ændre i en fil. F.eks. en fil jeg
ved bliver læst ofte af et cron-job og jeg ikke vil risikere at filen
ender smadret hvis mit (f.eks. Perl-) script stoppes midtvejs. Jeg
plejer at anvende rename(2) til atomart at erstatte filen med den nye
version.

Nu slår det mig bare. Det ændrer jo Inode'en og det er lidt skidt hvis
f.eks. Tripwire kører på maskinen. Jeg kunne selvfølgelig bede Tripwire
ignorere Inoden, men det ville være bedre hvis jeg kunne ændre filen
atomart uden at ændre Inode.

Advisory locking er ikke godt nok. Jeg er ikke klar over nogen mandatory
locking mekanisme der er tilpas standard til at kunne virke ligeså
generelt cross-platform som rename(2) gør det. D.v.s. basal POSIX.

Hvad er "standard" måden at gøre det her på?

Peter

---

Peter Mogensen <apm-at-mutex-dot-dk@nospam.not> writes:

> Nu slår det mig bare. Det ændrer jo Inode'en og det er lidt skidt hvis
> f.eks. Tripwire kører på maskinen. Jeg kunne selvfølgelig bede Tripwire
> ignorere Inoden, men det ville være bedre hvis jeg kunne ændre filen
> atomart uden at ændre Inode.

Du kunne bruge rename to gange.

Så vil inode kun blive ændret hvis programmet dør midt imellem
rename-kaldene.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
> Du kunne bruge rename to gange.
>
> Så vil inode kun blive ændret hvis programmet dør midt imellem
> rename-kaldene.

Huh? Eksempel?

Er det garanteret? eller er det en feature ved et bestemt fil-system?

Peter

---

Peter Mogensen <apm-at-mutex-dot-dk@nospam.not> writes:

> Kim Hansen wrote:
> > Du kunne bruge rename to gange.
> >
> > Så vil inode kun blive ændret hvis programmet dør midt imellem
> > rename-kaldene.
>
> Huh? Eksempel?

Metoden har den svaghed at man kommer til at mangle filen i kort tid
omkring rename-operationerne.

skriv ny data til : konfig.ny
rename : konfig -> konfig.old
rename : konfig.ny -> konfig
skriv nye data (igen) til : konfig.old
rename : konfig.old -> konfig

Så har man bevaret inode-nummeret i konfig, men der har mellem 1. og
2. rename været et vindue hvor filen ikke eksistrerede.


Men hvorfor er det problem at inode har ændret sig, du har jo også
ændret i filens indhold så dit tripwire system brokker sig vel
alligevel?

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
> Metoden har den svaghed at man kommer til at mangle filen i kort tid
> omkring rename-operationerne.
>
> skriv ny data til : konfig.ny
> rename : konfig -> konfig.old
> rename : konfig.ny -> konfig
> skriv nye data (igen) til : konfig.old
> rename : konfig.old -> konfig

Ahh.. 3 gange rename(2).
Joee....men som du selv siger... det er ikke 100% atomart.

> Men hvorfor er det problem at inode har ændret sig, du har jo også
> ændret i filens indhold så dit tripwire system brokker sig vel
> alligevel?

Et helt konkret eksempel er at jeg kører et Perl-kursus hvor jeg har
givet de studerende til opgave at skrive et program ala "service" - det
skal bare kunne rette i xinetd filer. D.v.s. man kører programmet:

myservice cvs stop
eller
myservice cvs start.

D.v.s. det er ikke sikkert at filindholdet ændrer sig. Det kommer an p[
hvad tilstanden var i forvejen. inoden vil derimod altid ændre sig med
rename(2).

Peter

---

Peter Mogensen <apm-at-mutex-dot-dk@nospam.not> writes:

> D.v.s. det er ikke sikkert at filindholdet ændrer sig. Det kommer an p[
> hvad tilstanden var i forvejen. inoden vil derimod altid ændre sig med
> rename(2).

Så anvender I vel noget i stil med? :

skriv ny data til : konfig.ny
rename : konfig.ny -> konfig

Kunne I så ikke bare checke om de to filer er ens inden rename, så vil
inode kun ændre sig hvis filen skifter indhold. Men det hjælper
selvfølgelig ikke hvis filen skifter to gange, og dermed slutter med
samme indhold som den startede med, men er nyt inodenummer.

--
Kim Hansen | |\ _,,,---,,_ | Det er ikke
Dalslandsgade 8, A708 | /,`.-'`' -. ;-;;,_ | Jeopardy.
2300 København S | |,4- ) )-,_. ,\ ( `'-' | Svar _efter_
Phone: 32 88 60 86 | '---''(_/--' `-'\_) | spørgsmålet.

---

Kim Hansen wrote:
> skriv ny data til : konfig.ny
> rename : konfig.ny -> konfig

Ja..

> Kunne I så ikke bare checke om de to filer er ens inden rename, så vil
> inode kun ændre sig hvis filen skifter indhold. Men det hjælper
> selvfølgelig ikke hvis filen skifter to gange, og dermed slutter med
> samme indhold som den startede med, men er nyt inodenummer.

Hmm..tjoe... der er jo bare et andet problem. Det er jo ikke helt
atomart alligevel. Der går et stykke tid fra filen læses til rename hvor
andre programmer i princippet kunne ændre i filen. :ndringer som ville
blive overskrevet. At diff'e filen inden rename gør jo ikke lige netop
dette tidsrum kortere.

Peter