hunyo, de kerek egy kis segitseget! :-)
kissg
--8<--- plocktest.c -8<--
#include
#include
#include
#include
#include
#include
int main(int argc, char **argv) {
char *filename;
int delay = 10;
struct flock lock;
Egy bizonyos program nem tudott lockfile-t letrehozni. Nezve, mi a gond,
azt talaltam, hogy azon a bizonyos gepen a /var/lock a root tulajdonaban
van, 0700 jogokkal.
Mas gepeken (mas disztribucio is) nezve /var/lock a root tulajdonaban
van, de 1777 jogokkal.
Az ugye latszik, hogy a konkret
> lock.l_start = 0;
> lock.l_len = 0;
Itt rontottad el. Ezzel igy nem lockol semmit.
A len legyen legalabb 1 byte.
_
linux lista - linux@mlf.linux.rulez.org
http://mlf2.linux.rulez.org/mailman/listinfo/linux
vitatkozom, mert nem akarok halatlannak
tunni, de Manuel szerint:
Specifying 0 for l_len has the special meaning: lock all bytes
starting at the location specified by l_whence and l_start
through to the end of file, no matter how large the file grows.
kissg
___
V.L. tagtarsunk talalt egy peldaprogramot, ami viszont mukodik:
http://www.ecst.csuchico.edu/~beej/guide/ipc/flock.html
Betettem a sajatomba a lock.l_pid = getpid() ertekadast, nem segitett.
Atirtam az O_WRONLY|O_APPEND-et O_RDWR-re, nem segitett.
Mas kulonbseget viszont nem latok a ketto kozott.
On Wed, 12 Sep 2007, [ISO-8859-1] Horváth Ágoston János wrote:
>> lock.l_start = 0;
>> lock.l_len = 0;
>
> Itt rontottad el. Ezzel igy nem lockol semmit.
> A len legyen legalabb 1 byte.
Nem biztos, mivel a len = 0 azt jelenti, hogy vegig megfogja a file-t.
Ez nalam mukodik:
htt
In article <[EMAIL PROTECTED]>,
[EMAIL PROTECTED] (Kiss Gabor) writes:
> Kifolyik a szemem, de nem latom mit toltam el.
Ez a megoldas:
if ((fd=open(filename,O_WRONLY|O_APPEND) == -1)) {
helyett
if ((fd=open(filename,O_WRONLY|O_APPEND)) == -1) {
> Igerem, haromszor is meg
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
Nagy Gabor Peter wrote:
>
> Mas gepeken (mas disztribucio is) nezve /var/lock a root tulajdonaban
> van, de 1777 jogokkal.
>
Ez a jo.
> Az ugye latszik, hogy a konkret programnak keves a 0700.
>
Nem csak root jogu processek lockolhatnak eroforrast.
> De, gondolom, vo
In article <[EMAIL PROTECTED]>,
Nagy Gabor Peter <[EMAIL PROTECTED]> writes:
> Nalatok mi a /var/lock joga? Mindenki irhat bele, csak legyen sticky?
1777
> Vagy jar ez valami hatrannyal?
Nem sulyos.
Barmely lokalis user ugy hasznalhatja, mint a /tmp-t.
Ki lehet tomn
Kiss Gabor írta:
> In article <[EMAIL PROTECTED]>,
> Nagy Gabor Peter <[EMAIL PROTECTED]> writes:
>
>> Nalatok mi a /var/lock joga? Mindenki irhat bele, csak legyen sticky?
>>
>
> 1777
>
>
>> Vagy jar ez valami hatrannyal?
Szia,
> >> Nalatok mi a /var/lock joga? Mindenki irhat bele, csak legyen
sticky?
Nekem Debian Etch:
# ls -l /var/ | grep lock
drwxrwxrwt 4 root root96 2007-05-09 09:23 lock
# stat /var/lock/ | grep Access
Access: (1777/drwxrwxrwt) Uid: (0/root) Gid: (0/
roo
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
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] 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
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,
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
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 hibauzen
[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, ha
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
> vegrehajth
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 m
21 matches
Mail list logo
