Rebase Permissions

[Stephen Rasku-3]

I am trying to rebase a repository that I didn't create but which I
have group write permission on:

$ ls -l .
total 40
drwxrwxr-x 114 hguser hg 4096 Nov  2 14:17 Dir1/
drwxrwxr-x   7 hguser hg 4096 Sep 10 15:43 Dir2/
drwxrwxr-x   2 hguser hg 4096 Oct 15 07:58 INC/
drwxrwxr-x   2 hguser hg 4096 Sep 10 15:43 psftp/
drwxrwxr-x  11 hguser hg 4096 Sep 10 15:43 www/

When I try and rebase it, I get the following error:

$ hg pull --reb
pulling from /var/hg/blah
searching for changes
adding changesets
adding manifests
adding file changes
added 159 changesets with 411 changes to 171 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
abort: Permission denied: /.../Dir1/newmodule/Makefile

This module doesn't exist in the repository prior to rebasing.  Why
would Mercurial create a file with permissions that the user running
the command can't use?

This is for version 1.3.1 on Linux.

...Stephen
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Mon, 2009-11-02 at 14:27 -0800, Stephen Rasku wrote:

> I am trying to rebase a repository that I didn't create but which I
> have group write permission on:
>
> $ ls -l .
> total 40
> drwxrwxr-x 114 hguser hg 4096 Nov  2 14:17 Dir1/
> drwxrwxr-x   7 hguser hg 4096 Sep 10 15:43 Dir2/
> drwxrwxr-x   2 hguser hg 4096 Oct 15 07:58 INC/
> drwxrwxr-x   2 hguser hg 4096 Sep 10 15:43 psftp/
> drwxrwxr-x  11 hguser hg 4096 Sep 10 15:43 www/
>
> When I try and rebase it, I get the following error:
>
> $ hg pull --reb
> pulling from /var/hg/blah
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 159 changesets with 411 changes to 171 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> abort: Permission denied: /.../Dir1/newmodule/Makefile
>
> This module doesn't exist in the repository prior to rebasing.  Why
> would Mercurial create a file with permissions that the user running
> the command can't use?

Mercurial does very little with permissions, so this is surprising.
What permission/ownership does that file end up getting? What filesystem
is involved?


--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[chadrik]

can you run that with the --traceback flag on?  i'm curious if this  
has to do with the issues i had with util.copyfile, which attempts to  
change file timestamps despite the fact that it is rarely necessary  
and impossible to do on a file you don't own.

-chad


On Nov 2, 2009, at 2:27 PM, Stephen Rasku wrote:

> I am trying to rebase a repository that I didn't create but which I
> have group write permission on:
>
> $ ls -l .
> total 40
> drwxrwxr-x 114 hguser hg 4096 Nov  2 14:17 Dir1/
> drwxrwxr-x   7 hguser hg 4096 Sep 10 15:43 Dir2/
> drwxrwxr-x   2 hguser hg 4096 Oct 15 07:58 INC/
> drwxrwxr-x   2 hguser hg 4096 Sep 10 15:43 psftp/
> drwxrwxr-x  11 hguser hg 4096 Sep 10 15:43 www/
>
> When I try and rebase it, I get the following error:
>
> $ hg pull --reb
> pulling from /var/hg/blah
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 159 changesets with 411 changes to 171 files (+1 heads)
> (run 'hg heads' to see heads, 'hg merge' to merge)
> abort: Permission denied: /.../Dir1/newmodule/Makefile
>
> This module doesn't exist in the repository prior to rebasing.  Why
> would Mercurial create a file with permissions that the user running
> the command can't use?
>
> This is for version 1.3.1 on Linux.
>
> ...Stephen
> _______________________________________________
> Mercurial mailing list
> Mercurial@...
> http://selenic.com/mailman/listinfo/mercurial

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

On Mon, Nov 2, 2009 at 14:55, Matt Mackall <mpm@...> wrote:
>
> Mercurial does very little with permissions, so this is surprising.
> What permission/ownership does that file end up getting? What filesystem
> is involved?

The file ends up with 755 permissions:

-rwxr-xr-x 1 hguser hg 811 Oct 15 07:58
/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile*

This happens for umask 022 and 002.

This is an ext3 filesystem running inside a VM.  I believe the VM is Xen:

 $ mount | grep var
/dev/mapper/vg0-lv03 on /var type ext3 (rw)

...Stephen
_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

Here's the traceback:

$ hg pull --reb --traceback
pulling from /var/hg/TUNet-0002
searching for changes
adding changesets
adding manifests
adding file changes
added 4 changesets with 16 changes to 16 files
(run 'hg update' to get a working copy)
Traceback (most recent call last):
  File "/usr/lib64/python2.4/site-packages/mercurial/dispatch.py",
line 43, in _runcatch
    return _dispatch(ui, args)
  File "/usr/lib64/python2.4/site-packages/mercurial/dispatch.py",
line 449, in _dispatch
    return runcommand(lui, repo, cmd, fullargs, ui, options, d)
  File "/usr/lib64/python2.4/site-packages/mercurial/dispatch.py",
line 317, in runcommand
    ret = _runcommand(ui, options, cmd, d)
  File "/usr/lib64/python2.4/site-packages/mercurial/dispatch.py",
line 501, in _runcommand
    return checkargs()
  File "/usr/lib64/python2.4/site-packages/mercurial/dispatch.py",
line 454, in checkargs
    return cmdfunc()
  File "/usr/lib64/python2.4/site-packages/mercurial/dispatch.py",
line 448, in <lambda>
    d = lambda: util.checksignature(func)(ui, *args, **cmdoptions)
  File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
402, in check
    return func(*args, **kwargs)
  File "/usr/lib64/python2.4/site-packages/mercurial/extensions.py",
line 102, in wrap
    return util.checksignature(wrapper)(
  File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
402, in check
    return func(*args, **kwargs)
  File "/usr/lib64/python2.4/site-packages/hgext/rebase.py", line 440,
in pullrebase
    rebase(ui, repo, **opts)
  File "/usr/lib64/python2.4/site-packages/hgext/rebase.py", line 118,
in rebase    collapsef, extrafn)
  File "/usr/lib64/python2.4/site-packages/hgext/rebase.py", line 202,
in rebasenode
    merge.update(repo, p1, False, True, False)
  File "/usr/lib64/python2.4/site-packages/mercurial/merge.py", line
468, in update
    stats = applyupdates(repo, action, wc, p2)
  File "/usr/lib64/python2.4/site-packages/mercurial/merge.py", line
306, in applyupdates
    repo.wwrite(f, t, flags)
  File "/usr/lib64/python2.4/site-packages/mercurial/localrepo.py",
line 605, in wwrite
    self.wopener(filename, 'w').write(data)
  File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
876, in __call__
    fp = posixfile(f, mode)
IOError: [Errno 13] Permission denied:
'/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
abort: Permission denied:
/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile

On Mon, Nov 2, 2009 at 17:23, chadrik <chadrik@...> wrote:

> can you run that with the --traceback flag on?  i'm curious if this has to
> do with the issues i had with util.copyfile, which attempts to change file
> timestamps despite the fact that it is rarely necessary and impossible to do
> on a file you don't own.
>
> -chad
>
>
> On Nov 2, 2009, at 2:27 PM, Stephen Rasku wrote:
>
>> I am trying to rebase a repository that I didn't create but which I
>> have group write permission on:
>>
>> $ ls -l .
>> total 40
>> drwxrwxr-x 114 hguser hg 4096 Nov  2 14:17 Dir1/
>> drwxrwxr-x   7 hguser hg 4096 Sep 10 15:43 Dir2/
>> drwxrwxr-x   2 hguser hg 4096 Oct 15 07:58 INC/
>> drwxrwxr-x   2 hguser hg 4096 Sep 10 15:43 psftp/
>> drwxrwxr-x  11 hguser hg 4096 Sep 10 15:43 www/
>>
>> When I try and rebase it, I get the following error:
>>
>> $ hg pull --reb
>> pulling from /var/hg/blah
>> searching for changes
>> adding changesets
>> adding manifests
>> adding file changes
>> added 159 changesets with 411 changes to 171 files (+1 heads)
>> (run 'hg heads' to see heads, 'hg merge' to merge)
>> abort: Permission denied: /.../Dir1/newmodule/Makefile
>>
>> This module doesn't exist in the repository prior to rebasing.  Why
>> would Mercurial create a file with permissions that the user running
>> the command can't use?
>>
>> This is for version 1.3.1 on Linux.
>>
>> ...Stephen
>> _______________________________________________
>> Mercurial mailing list
>> Mercurial@...
>> http://selenic.com/mailman/listinfo/mercurial
>
>

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
> Here's the traceback:
...
>     self.wopener(filename, 'w').write(data)
>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
> 876, in __call__
>     fp = posixfile(f, mode)

Hmm, posixfile here is simply open() and mode is simply 'w'.

> IOError: [Errno 13] Permission denied:
> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
> abort: Permission denied:
> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile

You said the file was owned by hguser. Are you not hguser?

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:

> On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
>> Here's the traceback:
> ...
>>     self.wopener(filename, 'w').write(data)
>>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
>> 876, in __call__
>>     fp = posixfile(f, mode)
>
> Hmm, posixfile here is simply open() and mode is simply 'w'.
>
>> IOError: [Errno 13] Permission denied:
>> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
>> abort: Permission denied:
>> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
>
> You said the file was owned by hguser. Are you not hguser?

No, I'm not hguser but I am a member of the group, hg, that hguser is
a member of.

...Stephen

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:

> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
> >> Here's the traceback:
> > ...
> >>     self.wopener(filename, 'w').write(data)
> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
> >> 876, in __call__
> >>     fp = posixfile(f, mode)
> >
> > Hmm, posixfile here is simply open() and mode is simply 'w'.
> >
> >> IOError: [Errno 13] Permission denied:
> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
> >> abort: Permission denied:
> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
> >
> > You said the file was owned by hguser. Are you not hguser?
>
> No, I'm not hguser but I am a member of the group, hg, that hguser is
> a member of.
>
> ...Stephen

Ok. Mercurial calculates the umask to use from the permissions of .hg/.
This means that if a user manages to create a repo with sensible
permissions, it continues to work. Sounds like the permissions on .hg
are not set to your liking.

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:

> On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
>> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
>> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
>> >> Here's the traceback:
>> > ...
>> >>     self.wopener(filename, 'w').write(data)
>> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
>> >> 876, in __call__
>> >>     fp = posixfile(f, mode)
>> >
>> > Hmm, posixfile here is simply open() and mode is simply 'w'.
>> >
>> >> IOError: [Errno 13] Permission denied:
>> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
>> >> abort: Permission denied:
>> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
>> >
>> > You said the file was owned by hguser. Are you not hguser?
>>
>> No, I'm not hguser but I am a member of the group, hg, that hguser is
>> a member of.
>>
>> ...Stephen
>
> Ok. Mercurial calculates the umask to use from the permissions of .hg/.
> This means that if a user manages to create a repo with sensible
> permissions, it continues to work. Sounds like the permissions on .hg
> are not set to your liking.

Just the .hg directory?  These are the permissioons on .hg directory:

$ ls -ld .hg
drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/

It has group write permission.  I would think that this would work.
What am I missing?  Everything in the .hg directory also has group
write permission but some is owned by me and some is owned by hguser.

...Stephen

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Tue, 2009-11-03 at 10:59 -0800, Stephen Rasku wrote:

> On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:
> > On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
> >> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
> >> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
> >> >> Here's the traceback:
> >> > ...
> >> >>     self.wopener(filename, 'w').write(data)
> >> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
> >> >> 876, in __call__
> >> >>     fp = posixfile(f, mode)
> >> >
> >> > Hmm, posixfile here is simply open() and mode is simply 'w'.
> >> >
> >> >> IOError: [Errno 13] Permission denied:
> >> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
> >> >> abort: Permission denied:
> >> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
> >> >
> >> > You said the file was owned by hguser. Are you not hguser?
> >>
> >> No, I'm not hguser but I am a member of the group, hg, that hguser is
> >> a member of.
> >>
> >> ...Stephen
> >
> > Ok. Mercurial calculates the umask to use from the permissions of .hg/.
> > This means that if a user manages to create a repo with sensible
> > permissions, it continues to work. Sounds like the permissions on .hg
> > are not set to your liking.
>
> Just the .hg directory?  These are the permissioons on .hg directory:
>
> $ ls -ld .hg
> drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/
>
> It has group write permission.  I would think that this would work.
> What am I missing?  Everything in the .hg directory also has group
> write permission but some is owned by me and some is owned by hguser.

Actually, it looks like we only manage modes specially in the store.
Everywhere else, I think we rely on umask. Perhaps your merge tool is
doing something interesting.

Generally speaking, having multiple users share a _working directory_ is
asking for trouble, and not just with permissions.

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

On Tue, Nov 3, 2009 at 11:11, Matt Mackall <mpm@...> wrote:

> On Tue, 2009-11-03 at 10:59 -0800, Stephen Rasku wrote:
>> On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:
>> > On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
>> >> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
>> >> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
>> >> >> Here's the traceback:
>> >> > ...
>> >> >>     self.wopener(filename, 'w').write(data)
>> >> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
>> >> >> 876, in __call__
>> >> >>     fp = posixfile(f, mode)
>> >> >
>> >> > Hmm, posixfile here is simply open() and mode is simply 'w'.
>> >> >
>> >> >> IOError: [Errno 13] Permission denied:
>> >> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
>> >> >> abort: Permission denied:
>> >> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
>> >> >
>> >> > You said the file was owned by hguser. Are you not hguser?
>> >>
>> >> No, I'm not hguser but I am a member of the group, hg, that hguser is
>> >> a member of.
>> >>
>> >> ...Stephen
>> >
>> > Ok. Mercurial calculates the umask to use from the permissions of .hg/.
>> > This means that if a user manages to create a repo with sensible
>> > permissions, it continues to work. Sounds like the permissions on .hg
>> > are not set to your liking.
>>
>> Just the .hg directory?  These are the permissioons on .hg directory:
>>
>> $ ls -ld .hg
>> drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/
>>
>> It has group write permission.  I would think that this would work.
>> What am I missing?  Everything in the .hg directory also has group
>> write permission but some is owned by me and some is owned by hguser.
>
> Actually, it looks like we only manage modes specially in the store.
> Everywhere else, I think we rely on umask. Perhaps your merge tool is
> doing something interesting.
>
> Generally speaking, having multiple users share a _working directory_ is
> asking for trouble, and not just with permissions.

Could you be more specific?

We are using this as gateway from CVS to Mercurial.  The hguser runs a
cron that runs every hour to pull the changes from CVS into Mercurial
but I would like any user in the hg group to be able to login and push
these changes to the official repository.  I don't expect that more
than one user will be manipulating the working directory at any one
time.  Could it still cause problems?

...Stephen

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Tue, 2009-11-03 at 11:16 -0800, Stephen Rasku wrote:

> On Tue, Nov 3, 2009 at 11:11, Matt Mackall <mpm@...> wrote:
> > On Tue, 2009-11-03 at 10:59 -0800, Stephen Rasku wrote:
> >> On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:
> >> > On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
> >> >> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
> >> >> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
> >> >> >> Here's the traceback:
> >> >> > ...
> >> >> >>     self.wopener(filename, 'w').write(data)
> >> >> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
> >> >> >> 876, in __call__
> >> >> >>     fp = posixfile(f, mode)
> >> >> >
> >> >> > Hmm, posixfile here is simply open() and mode is simply 'w'.
> >> >> >
> >> >> >> IOError: [Errno 13] Permission denied:
> >> >> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
> >> >> >> abort: Permission denied:
> >> >> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
> >> >> >
> >> >> > You said the file was owned by hguser. Are you not hguser?
> >> >>
> >> >> No, I'm not hguser but I am a member of the group, hg, that hguser is
> >> >> a member of.
> >> >>
> >> >> ...Stephen
> >> >
> >> > Ok. Mercurial calculates the umask to use from the permissions of .hg/.
> >> > This means that if a user manages to create a repo with sensible
> >> > permissions, it continues to work. Sounds like the permissions on .hg
> >> > are not set to your liking.
> >>
> >> Just the .hg directory?  These are the permissioons on .hg directory:
> >>
> >> $ ls -ld .hg
> >> drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/
> >>
> >> It has group write permission.  I would think that this would work.
> >> What am I missing?  Everything in the .hg directory also has group
> >> write permission but some is owned by me and some is owned by hguser.
> >
> > Actually, it looks like we only manage modes specially in the store.
> > Everywhere else, I think we rely on umask. Perhaps your merge tool is
> > doing something interesting.
> >
> > Generally speaking, having multiple users share a _working directory_ is
> > asking for trouble, and not just with permissions.
>
> Could you be more specific?
>
> We are using this as gateway from CVS to Mercurial.  The hguser runs a
> cron that runs every hour to pull the changes from CVS into Mercurial
> but I would like any user in the hg group to be able to login and push
> these changes to the official repository.  I don't expect that more
> than one user will be manipulating the working directory at any one
> time.  Could it still cause problems?

Well there's obviously no locking on files in the working dir (even
though there are locks on the internal state). Actually 'doing work' in
such a working directory is going to be problematic. But Mercurial
itself won't care, aside from requiring r/w access to everything.

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

On Tue, Nov 3, 2009 at 11:24, Matt Mackall <mpm@...> wrote:

> On Tue, 2009-11-03 at 11:16 -0800, Stephen Rasku wrote:
>> On Tue, Nov 3, 2009 at 11:11, Matt Mackall <mpm@...> wrote:
>> > On Tue, 2009-11-03 at 10:59 -0800, Stephen Rasku wrote:
>> >> On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:
>> >> > On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
>> >> >> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
>> >> >> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
>> >> >> >> Here's the traceback:
>> >> >> > ...
>> >> >> >>     self.wopener(filename, 'w').write(data)
>> >> >> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
>> >> >> >> 876, in __call__
>> >> >> >>     fp = posixfile(f, mode)
>> >> >> >
>> >> >> > Hmm, posixfile here is simply open() and mode is simply 'w'.
>> >> >> >
>> >> >> >> IOError: [Errno 13] Permission denied:
>> >> >> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
>> >> >> >> abort: Permission denied:
>> >> >> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
>> >> >> >
>> >> >> > You said the file was owned by hguser. Are you not hguser?
>> >> >>
>> >> >> No, I'm not hguser but I am a member of the group, hg, that hguser is
>> >> >> a member of.
>> >> >>
>> >> >> ...Stephen
>> >> >
>> >> > Ok. Mercurial calculates the umask to use from the permissions of .hg/.
>> >> > This means that if a user manages to create a repo with sensible
>> >> > permissions, it continues to work. Sounds like the permissions on .hg
>> >> > are not set to your liking.
>> >>
>> >> Just the .hg directory?  These are the permissioons on .hg directory:
>> >>
>> >> $ ls -ld .hg
>> >> drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/
>> >>
>> >> It has group write permission.  I would think that this would work.
>> >> What am I missing?  Everything in the .hg directory also has group
>> >> write permission but some is owned by me and some is owned by hguser.
>> >
>> > Actually, it looks like we only manage modes specially in the store.
>> > Everywhere else, I think we rely on umask. Perhaps your merge tool is
>> > doing something interesting.
>> >
>> > Generally speaking, having multiple users share a _working directory_ is
>> > asking for trouble, and not just with permissions.
>>
>> Could you be more specific?
>>
>> We are using this as gateway from CVS to Mercurial.  The hguser runs a
>> cron that runs every hour to pull the changes from CVS into Mercurial
>> but I would like any user in the hg group to be able to login and push
>> these changes to the official repository.  I don't expect that more
>> than one user will be manipulating the working directory at any one
>> time.  Could it still cause problems?
>
> Well there's obviously no locking on files in the working dir (even
> though there are locks on the internal state). Actually 'doing work' in
> such a working directory is going to be problematic. But Mercurial
> itself won't care, aside from requiring r/w access to everything.

Base on this it sounds like it shouldn't be a problem.  No-one is
really "doing work" in this directory.  They just need to push any
changes to the official repository rebasing if necessary.

However, it seems that umask is being ignored.  The newly created
directory is always being created without group write permission even
if umask is 002.  I am not using a merge tool other than the rebase
extension.  kdiff3 is configured but it wasn't launched.  It shouldn't
have affected the specified file because it is new on the pulled
changesets.  It doesn't exist in the local repository.

...Stephen

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Matt Mackall]

On Tue, 2009-11-03 at 11:50 -0800, Stephen Rasku wrote:

> On Tue, Nov 3, 2009 at 11:24, Matt Mackall <mpm@...> wrote:
> > On Tue, 2009-11-03 at 11:16 -0800, Stephen Rasku wrote:
> >> On Tue, Nov 3, 2009 at 11:11, Matt Mackall <mpm@...> wrote:
> >> > On Tue, 2009-11-03 at 10:59 -0800, Stephen Rasku wrote:
> >> >> On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:
> >> >> > On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
> >> >> >> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
> >> >> >> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
> >> >> >> >> Here's the traceback:
> >> >> >> > ...
> >> >> >> >>     self.wopener(filename, 'w').write(data)
> >> >> >> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
> >> >> >> >> 876, in __call__
> >> >> >> >>     fp = posixfile(f, mode)
> >> >> >> >
> >> >> >> > Hmm, posixfile here is simply open() and mode is simply 'w'.
> >> >> >> >
> >> >> >> >> IOError: [Errno 13] Permission denied:
> >> >> >> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
> >> >> >> >> abort: Permission denied:
> >> >> >> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
> >> >> >> >
> >> >> >> > You said the file was owned by hguser. Are you not hguser?
> >> >> >>
> >> >> >> No, I'm not hguser but I am a member of the group, hg, that hguser is
> >> >> >> a member of.
> >> >> >>
> >> >> >> ...Stephen
> >> >> >
> >> >> > Ok. Mercurial calculates the umask to use from the permissions of .hg/.
> >> >> > This means that if a user manages to create a repo with sensible
> >> >> > permissions, it continues to work. Sounds like the permissions on .hg
> >> >> > are not set to your liking.
> >> >>
> >> >> Just the .hg directory?  These are the permissioons on .hg directory:
> >> >>
> >> >> $ ls -ld .hg
> >> >> drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/
> >> >>
> >> >> It has group write permission.  I would think that this would work.
> >> >> What am I missing?  Everything in the .hg directory also has group
> >> >> write permission but some is owned by me and some is owned by hguser.
> >> >
> >> > Actually, it looks like we only manage modes specially in the store.
> >> > Everywhere else, I think we rely on umask. Perhaps your merge tool is
> >> > doing something interesting.
> >> >
> >> > Generally speaking, having multiple users share a _working directory_ is
> >> > asking for trouble, and not just with permissions.
> >>
> >> Could you be more specific?
> >>
> >> We are using this as gateway from CVS to Mercurial.  The hguser runs a
> >> cron that runs every hour to pull the changes from CVS into Mercurial
> >> but I would like any user in the hg group to be able to login and push
> >> these changes to the official repository.  I don't expect that more
> >> than one user will be manipulating the working directory at any one
> >> time.  Could it still cause problems?
> >
> > Well there's obviously no locking on files in the working dir (even
> > though there are locks on the internal state). Actually 'doing work' in
> > such a working directory is going to be problematic. But Mercurial
> > itself won't care, aside from requiring r/w access to everything.
>
> Base on this it sounds like it shouldn't be a problem.  No-one is
> really "doing work" in this directory.  They just need to push any
> changes to the official repository rebasing if necessary.
>
> However, it seems that umask is being ignored.  The newly created
> directory is always being created without group write permission even
> if umask is 002.  I am not using a merge tool other than the rebase
> extension.  kdiff3 is configured but it wasn't launched.  It shouldn't
> have affected the specified file because it is new on the pulled
> changesets.  It doesn't exist in the local repository.

How mysterious. Perhaps you could try instrumenting
mercurial/util.py:makedirs().

--
http://selenic.com : development and support for Mercurial and Linux


_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial

[Stephen Rasku-3]

On Tue, Nov 3, 2009 at 13:34, Matt Mackall <mpm@...> wrote:

> On Tue, 2009-11-03 at 11:50 -0800, Stephen Rasku wrote:
>> On Tue, Nov 3, 2009 at 11:24, Matt Mackall <mpm@...> wrote:
>> > On Tue, 2009-11-03 at 11:16 -0800, Stephen Rasku wrote:
>> >> On Tue, Nov 3, 2009 at 11:11, Matt Mackall <mpm@...> wrote:
>> >> > On Tue, 2009-11-03 at 10:59 -0800, Stephen Rasku wrote:
>> >> >> On Tue, Nov 3, 2009 at 10:54, Matt Mackall <mpm@...> wrote:
>> >> >> > On Tue, 2009-11-03 at 10:51 -0800, Stephen Rasku wrote:
>> >> >> >> On Tue, Nov 3, 2009 at 10:42, Matt Mackall <mpm@...> wrote:
>> >> >> >> > On Tue, 2009-11-03 at 09:29 -0800, Stephen Rasku wrote:
>> >> >> >> >> Here's the traceback:
>> >> >> >> > ...
>> >> >> >> >>     self.wopener(filename, 'w').write(data)
>> >> >> >> >>   File "/usr/lib64/python2.4/site-packages/mercurial/util.py", line
>> >> >> >> >> 876, in __call__
>> >> >> >> >>     fp = posixfile(f, mode)
>> >> >> >> >
>> >> >> >> > Hmm, posixfile here is simply open() and mode is simply 'w'.
>> >> >> >> >
>> >> >> >> >> IOError: [Errno 13] Permission denied:
>> >> >> >> >> '/var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile'
>> >> >> >> >> abort: Permission denied:
>> >> >> >> >> /var/cvshg/INC/TUNet-0002/BASE_STATION/newmodule/Makefile
>> >> >> >> >
>> >> >> >> > You said the file was owned by hguser. Are you not hguser?
>> >> >> >>
>> >> >> >> No, I'm not hguser but I am a member of the group, hg, that hguser is
>> >> >> >> a member of.
>> >> >> >>
>> >> >> >> ...Stephen
>> >> >> >
>> >> >> > Ok. Mercurial calculates the umask to use from the permissions of .hg/.
>> >> >> > This means that if a user manages to create a repo with sensible
>> >> >> > permissions, it continues to work. Sounds like the permissions on .hg
>> >> >> > are not set to your liking.
>> >> >>
>> >> >> Just the .hg directory?  These are the permissioons on .hg directory:
>> >> >>
>> >> >> $ ls -ld .hg
>> >> >> drwxrwxr-x 4 hguser hg 4096 Nov  3 09:26 .hg/
>> >> >>
>> >> >> It has group write permission.  I would think that this would work.
>> >> >> What am I missing?  Everything in the .hg directory also has group
>> >> >> write permission but some is owned by me and some is owned by hguser.
>> >> >
>> >> > Actually, it looks like we only manage modes specially in the store.
>> >> > Everywhere else, I think we rely on umask. Perhaps your merge tool is
>> >> > doing something interesting.
>> >> >
>> >> > Generally speaking, having multiple users share a _working directory_ is
>> >> > asking for trouble, and not just with permissions.
>> >>
>> >> Could you be more specific?
>> >>
>> >> We are using this as gateway from CVS to Mercurial.  The hguser runs a
>> >> cron that runs every hour to pull the changes from CVS into Mercurial
>> >> but I would like any user in the hg group to be able to login and push
>> >> these changes to the official repository.  I don't expect that more
>> >> than one user will be manipulating the working directory at any one
>> >> time.  Could it still cause problems?
>> >
>> > Well there's obviously no locking on files in the working dir (even
>> > though there are locks on the internal state). Actually 'doing work' in
>> > such a working directory is going to be problematic. But Mercurial
>> > itself won't care, aside from requiring r/w access to everything.
>>
>> Base on this it sounds like it shouldn't be a problem.  No-one is
>> really "doing work" in this directory.  They just need to push any
>> changes to the official repository rebasing if necessary.
>>
>> However, it seems that umask is being ignored.  The newly created
>> directory is always being created without group write permission even
>> if umask is 002.  I am not using a merge tool other than the rebase
>> extension.  kdiff3 is configured but it wasn't launched.  It shouldn't
>> have affected the specified file because it is new on the pulled
>> changesets.  It doesn't exist in the local repository.
>
> How mysterious. Perhaps you could try instrumenting
> mercurial/util.py:makedirs().

I could if I knew how.  In the meantime I've updated the directory
using the owner user, hguser.  I am happy to do any testing or
diagnostics the next time this occurs.

...Stephen

_______________________________________________
Mercurial mailing list
Mercurial@...
http://selenic.com/mailman/listinfo/mercurial