Bug 337129 - permissions not properly set when repo is configured as sharedrepository
Summary: permissions not properly set when repo is configured as sharedrepository
Status: NEW
Alias: None
Product: JGit
Classification: Technology
Component: JGit (show other bugs)
Version: 0.11   Edit
Hardware: All All
: P3 enhancement (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-02-14 09:30 EST by Alvaro Sanchez-Leon CLA
Modified: 2011-02-21 09:42 EST (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alvaro Sanchez-Leon CLA 2011-02-14 09:30:10 EST
If a git repository is configured using the option
  sharedrepository e.g. = 0666

the permissions of the created files or directories are expected to follow the shared flags e.g. above should provide read and write permissions for everyone.

However, when using Egit/Jgit the permissions applied seem to follow the umask set at the user level (in Linux), in Windows the write flag is not set.

The testing configuration is as follows:

a bare repository created in a central linux file system using the following config.
the bare repository was created from a packed repository.

$ cat config
[core]
        repositoryformatversion = 0
        filemode = false
        bare = true
        symlinks = false
        ignorecase = true
        hideDotFiles = dotGitOnly
        sharedrepository = 0666


a windows client clone configuration set to e.g.
[core]
	repositoryformatversion = 0
	filemode = false
	logallrefupdates = true
	autocrlf = false
	bare = false
	sharedrepository = 0666
[remote "origin"]
	url = file:///X:/share_r4e_test/org.eclipse.mylyn.reviews.git
	fetch = +refs/heads/*:refs/remotes/origin/*
[branch "master"]
	remote = origin
	merge = refs/heads/master


a similar configuration for a client in Linux was also used.


NOTE: When using msysGit (c implementation) the permissions are reflecting the sharerepository flag.
Comment 1 Alvaro Sanchez-Leon CLA 2011-02-15 14:30:11 EST
The behavior is a bit different when the bare repository is packed vs unpacked. However the interesting areas where the file permissions need to be updated seem to be in the following files and folders (i.e. experienced push permission errors).

   refs/heads/*
   logs/refs/heads/*

The following folders may also need to be considered:
   file: packed-refs