Re: file lock kerdes
Sziasztok! tartja nyitva folyamatosan. Ha birod lemezterulettel, probald meg mc-vel megnyitni *mikozben* megy bele a cat. Erre jutottam en is, sot, kiprobaltam. Elinditottam ket ablakban egymas mellett egy kb. 340M konyvtar osszecsomagolasat: ~$ tar -cvf munka.tar Munka/* Enter utan klikk a masik terminalra es ott is enter. Siman lefutott mindketto, sot a 2. terminal beerte az 1.-t es a kepernyon amennyire kovethettem, ezutan tokeletesen szinkronban mentek (reprodukalhato). Hibauzenet egy szal sem. A tar fajl elkeszult es benne minden rendben. Kozben egy harmadik terminalban lathattam a filemeret novekedeset, egyertelmu, hogy irtak a fajlba. Ha ket kulonbozo konyvtar csomagolasat inditom a terminalokban, a masodjara indulo kerul a fajlba. Ez persze igy nem teljesen korrekt, mert mereteben a ketto mentes osszege lett, de kicsomagolni belole csak a masodikat lehet. Ext3-n (debian) es ReiserFS-n (opensuse) is igy sikerult. Most van min gondolkodnom. Udv.: Laci -- Baranyai Laszlo <[EMAIL PROTECTED]> Corvinus University of Budapest _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
SZABO Zsolt wrote: > Egy ext2/3 fs-en belul, hogyan tudom megakadalyozni, hogy ket processz > egyidejuleg read-write modon ferhessen hozza egy file-hoz? > Neztem a mount 'mand' opciojat es az fcntl leirasat, ami szerint a > 'mand' mellett az adott file-ra set-GID bit kell, de ne legyen > vegrehajthato (chmod g-x, chmod g+s). Ennek ellenere probaltam mc-vel > szerkeszteni, meg bele cat-olni egyszerre, es ment gond nelkul. Ez nem jelent semmit. mc megnyitja a fajlt, kiolvassa a tartalmat, beteszi az editorba, majd bezarja. Ha mentesz, megint megnyitja, beleirja a memoriabol a szerkesztett szoveget, majd bezarja. Szoval nem tartja nyitva folyamatosan. Ha birod lemezterulettel, probald meg mc-vel megnyitni *mikozben* megy bele a cat. _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
[EMAIL PROTECTED] wrote: Amikor a manualt olvastam, úgy tűnt, hogy a mandatory locking is csak akkor játszik, ha az alkalmazás flock()-ot hív. Ez így is van, így érvényesíti a lezárást, de a konkurrens alkalmazásnak nem kell (nem muszáj) vizsgálnia (flock visszatérése) hogy lockolt-e a file, hanem egyszerűen nem tudja megnyitni és kész. -- Hofferek Attila _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
On Thu, 9 Feb 2006, Laszlo Baranyai wrote: > > vegrehajthato (chmod g-x, chmod g+s). Ennek ellenere probaltam mc-vel > > szerkeszteni, meg bele cat-olni egyszerre, es ment gond nelkul. > Mert a szerkeszto nem lock-olja. Probald meg vi/gvim -val/vel, es latni > fogod a hibauzenetet a valtozasrol (vi-nal menteskor). A vi-nak van egy saját lockfile-ja, azt használja (és persze a többi alkalmazás figyelmen kívűl hagyja). Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
On Thu, 9 Feb 2006, Hofferek Attila wrote: > [EMAIL PROTECTED] wrote: > > Tudtommal az alkalmazásnak kell erre explicit figyelnie (flock() hívás), > > a kernel feltételezi a userekről, hogy tudják, mit csinálnak. > > A ,,normál'' advisory lockingnál így is van, de a mandatory lockingnak > pont az a lényege, hogy akár figyel a másik alkalmazás a locking > statusra, akár nem, amíg lockolva van, nem lehet megnyitni a file-t. Amikor a manualt olvastam, úgy tűnt, hogy a mandatory locking is csak akkor játszik, ha az alkalmazás flock()-ot hív. Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
On Thu, 9 Feb 2006, Hofferek Attila wrote: [EMAIL PROTECTED] wrote: Tudtommal az alkalmazásnak kell erre explicit figyelnie (flock() hívás), a kernel feltételezi a userekről, hogy tudják, mit csinálnak. A ,,normál'' advisory lockingnál így is van, de a mandatory lockingnak pont az a lényege, hogy akár figyel a másik alkalmazás a locking statusra, akár nem, amíg lockolva van, nem lehet megnyitni a file-t. Ezek szerint valamilyen beallitas meg hianyzik nalam, hogy ez valoban mukodjon... (a "mand" opcio nem fs fuggo, ugye?) sZs _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
[EMAIL PROTECTED] wrote: Tudtommal az alkalmazásnak kell erre explicit figyelnie (flock() hívás), a kernel feltételezi a userekről, hogy tudják, mit csinálnak. A ,,normál'' advisory lockingnál így is van, de a mandatory lockingnak pont az a lényege, hogy akár figyel a másik alkalmazás a locking statusra, akár nem, amíg lockolva van, nem lehet megnyitni a file-t. -- Hofferek Attila _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
vegrehajthato (chmod g-x, chmod g+s). Ennek ellenere probaltam mc-vel szerkeszteni, meg bele cat-olni egyszerre, es ment gond nelkul. Mert a szerkeszto nem lock-olja. Probald meg vi/gvim -val/vel, es latni fogod a hibauzenetet a valtozasrol (vi-nal menteskor). Udv.: Laci -- Laszlo Baranyai <[EMAIL PROTECTED]> Corvinus University of Budapest _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux
Re: file lock kerdes
On Thu, 9 Feb 2006, SZABO Zsolt wrote: > Nem egeszen vilagos ez szamomra... > > Egy ext2/3 fs-en belul, hogyan tudom megakadalyozni, hogy ket processz > egyidejuleg read-write modon ferhessen hozza egy file-hoz? > Neztem a mount 'mand' opciojat es az fcntl leirasat, ami szerint a 'mand' > mellett az adott file-ra set-GID bit kell, de ne legyen vegrehajthato (chmod > g-x, chmod g+s). Ennek ellenere probaltam mc-vel szerkeszteni, meg bele > cat-olni egyszerre, es ment gond nelkul. Tudtommal az alkalmazásnak kell erre explicit figyelnie (flock() hívás), a kernel feltételezi a userekről, hogy tudják, mit csinálnak. [...] > Bonusz kerdes: milyen mas filerendszer van az ext2/3-on kivul, ami az ilyen > multiuseres kornyezetet hatekonyabban tamogatja? A különbőző felhasználók miért nem használnak különböző userid-ket és akkor és akkor egyáltalán nem tudják egymás file-jait szerkeszteni? Vagy célszerű lehet az egészet valami verziókövető renszer alá tenni, ha úgyis csapatmunka van. Bye,NAR -- "Beware of bugs in the above code; I have only proved it correct, not tried it." _ linux lista - linux@mlf.linux.rulez.org http://mlf2.linux.rulez.org/mailman/listinfo/linux