Date: Fri, 13 Mar 2015 11:50:53 +1030 From: "O'Connor, Daniel" <darius@dons.net.au> To: Mateusz Guzik <mjguzik@gmail.com> Cc: freebsd-hackers@FreeBSD.org, Don Lewis <truckman@FreeBSD.org>, int0dster@gmail.com, oliver.pinter@hardenedbsd.org, shawn.webb@hardenedbsd.org Subject: Re: file system change notifications Message-ID: <3C95016C-23D4-4827-A70D-803FD441255F@dons.net.au> In-Reply-To: <20150312143814.GA9153@dft-labs.eu> References: <20150311224831.GB18699@dft-labs.eu> <201503112318.t2BNIboU092815@gw.catspoiler.org> <20150312143814.GA9153@dft-labs.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 13 Mar 2015, at 01:08, Mateusz Guzik <mjguzik@gmail.com> wrote: >> I seem to recall reading a long time ago that DragonFly pins = directories >> in the cache, or something like that. >>=20 >=20 > Just refing is quite insufficient and may not work at all. >=20 > Due to hardlinks files can have more than one name. >=20 > So preferably we would stop tossing vnodes around and create an > intermediate object which would keep name component and a pointer to = an > inode. And that's what we would keep in struct file. >=20 > Then a namecache would just be a hash of such objects. >=20 > That's quite a lot of work though and unfortunately is likely too > complicated for gsoc. I did some testing and neither Linux inotify or OS X FSEvents handle = hard links so I think it's somewhat out of scope. i.e. if you create /tmp/a and /tmp/b and have 2 separate processes = watching /tmp/a and /tmp/b then do.. 1) echo foo >/tmp/a/foo 2) ln /tmp/a/foo /tmp/b/foo 3) echo bar >/tmp/b/foo Step 1 shows a notification for /tmp/a/foo Step 2 shows a notification for /tmp/b/foo (and /tmp/a in OS X) Step 3 shows a notification for /tmp/b/foo (even though /tmp/a has = changed too) -- Daniel O'Connor "The nice thing about standards is that there are so many of them to choose from." -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3C95016C-23D4-4827-A70D-803FD441255F>