On 13 Jan 2010, at 4:23 pm, Enrico Weigelt wrote:
* erik quanstrom quans...@quanstro.net wrote:
i think you misunderstand the problem. cookiefs' fs interface
is not the issue. cookiefs' robustness when storing the cookies
on the fileserver in the face of multiple concurrently running
On Mon Jan 25 15:15:42 EST 2010, eeke...@fastmail.fm wrote:
On 13 Jan 2010, at 4:23 pm, Enrico Weigelt wrote:
* erik quanstrom quans...@quanstro.net wrote:
i think you misunderstand the problem. cookiefs' fs interface
is not the issue. cookiefs' robustness when storing the cookies
but how do you get into that situation in the first place ?
(more to the point: who starts these multiple instances ?)
cookiefs (or upas/fs, etc.) running on multiple terminals
connected to the same shared file server. or in multiple windows.
russ
* erik quanstrom quans...@quanstro.net wrote:
i think you misunderstand the problem. cookiefs' fs interface
is not the issue. cookiefs' robustness when storing the cookies
on the fileserver in the face of multiple concurrently running
cookiefs' is.
ah, you're talking about the situation
* Russ Cox r...@swtch.com wrote:
what's really wanted here is an atomic create/write/close so that
one process (we don't care which one) is responsible for the whole
file. i think you could get this behavior by creating a temporary
keyfile and then an rename (wstat), which is atomic.
Just curious: can an 9P server cleanly differenciate between clients ?
This would be a great help for transaction isolation, IMHO.
w/o having looked at cookiefs yet, but I would do it like that:
* get cookies by reading /site-cookies/site
* set cookies by writing site: foo=bar to
Hi,
Actually I stumbled upon the DMEXCL support trying to use webfs and
webcookies in order to run abaco.
As I see from webcookies source code, all cookies are stored in one
file, that's why exclusive access is necessary.
Will anything get worse if each cookie is stored in its own file* ?
And
Will anything get worse if each cookie is stored in its own file* ?
if a site has more than 1 cookie managed as a pair, you could
get them out-of-sync by not locking.
what's really wanted here is an atomic create/write/close so that
one process (we don't care which one) is responsible for the
