Re: Empty directories...

Johannes Schindelin [off-list ref] writes:

quoted

quoted

We do not track permissions of directories at all.

Ok, this seems like something that should be done as well, even if we
can stipulate at first that a directory should have rwx for the user
in question if you hope to track it.

No, no, no.  It should not be tracked.  It is the responsibility of the 
_user_ to set it to something sane, be that by a umask or by sticky 
groups, or by setting the permissions of the parent directory.

It is _nothing_ we want to put into the repository.  That is the _wrong_ 
place to put it.

I'm not sure it's wrong to be able to track permissions, but it's
definitely wrong to track them by default.

GNU Arch had some permission tracking, and I got hit by it several
times. You have several things you might have wanted to track:

* read/write for the user. But I can't imagine a case where you
  wouldn't want to be able to read and write your own files.

* permissions for group. But that doesn't make any sense when several
  persons work on the same project, and don't share the same
  /etc/group.

* permissions for others. But that, again, doesn't make sense when
  several persons work on the same project with different setups. I
  sometimes work at home, where I'm basically the only user, I don't
  care at all about permissions for others. At work, it's totally
  different, since it's a big NFS shared by all the lab. And I might
  very well disclose my work to the rest of the lab, and work with
  someone who do not want to do so.

* Execute bit. This one is relevant. Indeed, it's more a kind of
  metadata than really a permission (you can still execute the file
  with /lib/ld-linux.so.2 /path/to/file or such kind of things).

Using GNU Arch, I got the cases in real life of a project in which
some files had group read permission, some other not, because they
were created by developers having different umask. Worse than this, I
got some group-writable files in my $HOME without noticing it, which
is basically a security hole.

-- 
Matthieu

Matthieu Moy [off-list ref] writes:

Johannes Schindelin [off-list ref] writes:

quoted

quoted

quoted

We do not track permissions of directories at all.

Ok, this seems like something that should be done as well, even if we
can stipulate at first that a directory should have rwx for the user
in question if you hope to track it.

No, no, no.  It should not be tracked.  It is the responsibility of the 
_user_ to set it to something sane, be that by a umask or by sticky 
groups, or by setting the permissions of the parent directory.

It is _nothing_ we want to put into the repository.  That is the _wrong_ 
place to put it.

I'm not sure it's wrong to be able to track permissions, but it's
definitely wrong to track them by default.

I am not sure about "definitely", but there certainly are applications
where it is appropriate.

* Execute bit. This one is relevant. Indeed, it's more a kind of
  metadata than really a permission (you can still execute the file
  with /lib/ld-linux.so.2 /path/to/file or such kind of things).

Please spare us the sophistry.  Probably the most flexible approach
would be to be able to specify a checkout umask, defaulting to 700
(the other bits are then filled in from the normal user umask).  For
archival purposes, one would then set it to 777 instead.

There is the question how to deal with checkins.  While there is no
harm in checking in the full permissions in case one would need them,
it would likely be a nuisance to track the individual contributor's
settings.

-- 
David Kastrup