[Unison-hackers] Need fix for chmod problem

[Jerome Vouillon]

On Tue, Oct 04, 2005 at 04:50:29PM +0300, Benjamin Pierce wrote:
> I agree that the code in question looks wrong as it stands, and I've  
> made this change in the developer sources.
> 
> Trevor, Jerome -- do you agree?

This is a tricky issue.

First, when Unison propagates a file content modification, one
probably want to preserve as much as possible the permissions of the
previous version of the file (which is being overwritten by Unison),
even when not all permission bits are synchronized.  For instance, a
file which is readable by anybody should probably remain so even when
no permission is synchronized.  This is the reason for the special
case when kind = `Set.

Second, when a file or a directory is created, its permissions are not
always exactly the permissions given to the mkdir or open system call:
they depend on the process's umask and (for directory) on whether the
parent directory has a set group ID bit set.  If we want a consistent
behavior, Unison should either unconditionally set the full
permissions afterwards as is done now, or look at the file system to
see what the permissions was set to and only update the bits which are
synchronized.

Third, on some filesystem, chmod can fail for some permissions.  Thus,
Unison should only change the values of the synchronized bits.  This
is not the case at the moment.

Thus, I think the right fix is to change, in file fileinfo.ml, in
function set, the following piece of code:

      `Set defDesc ->
        (* Set the permissions and maybe the other properties                *)
        `Set, Props.override defDesc newDesc

into:

      `Set defDesc ->
        (* Set the permissions and maybe the other properties                *)
        `Set, Props.override (get false fspath path).desc newDesc

It would probably be clearer to turn the expression "kind <> `Update"
into "kind = `Set" in file props.ml.  Also, this part of the code
could be better documented...

Dale, could you try this change?  Thanks a lot for your mail.  This
was a good opportunity for me to think about this issue.

Benjamin, could you make the change (if Dale is happy with it).  I
have not yet migrated to the new svn repository.

-- Jerome