On 6/9/2011 12:25 PM, Vincent Ladeuil wrote:
> Hmm, there should be two problematic areas in this case: log and locks.
>
> In both cases, there should be somw workaround via env variables (which
> are a pain on windows but probably still the easiest).
>
> This may lead to several different bugs so if you can document your own
> workarounds here that would be great.
>
You can set %USER% for the service, and I think it makes everything
work. So there is a reasonable workaround.
We certainly can avoid pwd, but that just falls back into "we don't know
the user to take the lock as". We certainly should be able to give a
better error message. On Windows if we get to the 'pwd' section, we
could just raise an error saying "unable to determine user identity,
please set USER" or something to that effect.
AFAIK, we don't have any way to even get the service identity. If you
know of any Win32 api call that can give us something to use, I think
we'd be happy to use it.
We could fall back to "<generic-unknown-user>" or something like that,
but I think that isn't a very satisfactory answer, either.
There is one further change, but probably a different bug. Which is that
performing an RPC that would take a lock server-side, could pass client
information. So the lock would contain "locked-by SERVER on-behalf of
USER" sort of thing. I don't know that it is worth much just yet, though.
John
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On 6/9/2011 12:25 PM, Vincent Ladeuil wrote:
> Hmm, there should be two problematic areas in this case: log and locks.
>
> In both cases, there should be somw workaround via env variables (which
> are a pain on windows but probably still the easiest).
>
> This may lead to several different bugs so if you can document your own
> workarounds here that would be great.
>
You can set %USER% for the service, and I think it makes everything
work. So there is a reasonable workaround.
We certainly can avoid pwd, but that just falls back into "we don't know
the user to take the lock as". We certainly should be able to give a
better error message. On Windows if we get to the 'pwd' section, we
could just raise an error saying "unable to determine user identity,
please set USER" or something to that effect.
AFAIK, we don't have any way to even get the service identity. If you
know of any Win32 api call that can give us something to use, I think
we'd be happy to use it.
We could fall back to "<generic- unknown- user>" or something like that,
but I think that isn't a very satisfactory answer, either.
There is one further change, but probably a different bug. Which is that
performing an RPC that would take a lock server-side, could pass client
information. So the lock would contain "locked-by SERVER on-behalf of
USER" sort of thing. I don't know that it is worth much just yet, though.
John enigmail. mozdev. org/
=:->
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://
iEYEARECAAYFAk3 wof4ACgkQJdeBCY SNAAO3KACgufs3X bL17adItNsLNmfr nCrd pkGM/1OyQoYm22w yy
jpcAoKq6HshUvhY
=utqe
-----END PGP SIGNATURE-----