brian m. carlson sand...@crustytoothpaste.net writes:
On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); //
On Tue, Feb 17, 2015 at 09:51:38AM +0100, Matthieu Moy wrote:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return
Torsten Bögershausen tbo...@web.de writes:
On 17/02/15 17:58, Fairuzan Roslan wrote:
$ rm -rf testdir
rm: testdir/testfile: Operation not permitted
rm: testdir: Directory not empty
This works on my system (Mac OS 10.9 as server and client)
Just to be sure: by work, you mean successfully
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
in compat/broken-unlink.c and something like this
#ifdef BROKEN_UNLINK
#define unlink(x) workaround_broken_unlink(x)
#endif
in git-compat-util.h instead?
That means we have to
Junio C Hamano gits...@pobox.com writes:
in compat/broken-unlink.c and something like this
#ifdef BROKEN_UNLINK
#define unlink(x) workaround_broken_unlink(x)
#endif
in git-compat-util.h instead?
That means we have to know BROKEN_UNLINK at compile-time. I had never
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Junio C Hamano gits...@pobox.com writes:
in compat/broken-unlink.c and something like this
#ifdef BROKEN_UNLINK
#define unlink(x) workaround_broken_unlink(x)
#endif
in
On Feb 18, 2015, at 10:05 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
Client: OS X 10.9 - 10.10.2
git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1
Server : Linux 3.2.40 (Synology DSM 5.1)
AFP : Netatalk
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
Client: OS X 10.9 - 10.10.2
git client: git version 1.9.3 (Apple Git-50) and git version 2.2.1
Server : Linux 3.2.40 (Synology DSM 5.1)
AFP : Netatalk afpd 3.1.1
Any chance you can test this with a Mac OS server?
Perhaps because the server
On Feb 18, 2015, at 4:15 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
And now I'm starting to wonder whether other people do have the same
issue. Sure, googling Git AFP shows a lot of people having problems
with Git and AFP, but are they really the same problem?
I googled 'git
Matthieu Moy matthieu@grenoble-inp.fr writes:
This should be fixable from Git itself, by replacing the calls to
unlink with something like
int unlink_or_chmod(...) {
if (unlink(...)) {
chmod(...); // give user write permission
return unlink(...);
On Feb 17, 2015, at 4:51 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0),
On 17/02/15 17:58, Fairuzan Roslan wrote:
On Feb 17, 2015, at 4:51 PM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects:
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
$ git clone https://github.com/robbyrussell/oh-my-zsh.git
Cloning into 'oh-my-zsh'...
remote: Counting objects: 11830, done.
remote: Total 11830 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (11830/11830), 2.12 MiB | 481.00 KiB/s,
Hi,
Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are causing a lot
of issues (unable to unlink/write/rename) to those people who use AFP shares.
In order to be able to write/unlink/delete/rename a file on AFP filesystem the
owner of the file must have at least a u+w access to
I don’t see the issue for the owner of his/her own file to have write access.
Setting tmp idx pack files to read-only even for the file owner is not a
safety feature.
The real issue here is that in AFP file system can’t even unlink or rename or
delete the tmp idx and pack file with no write
Matthieu Moy matthieu@grenoble-inp.fr writes:
The issue is that having object and pack files read-only on the
filesystem is a safety feature to prevent accidental modifications (even
though it's actually not that effective, since brute-force sed -i or
perl -i still accept to modify
On 16.02.15 20:06, Junio C Hamano wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
The issue is that having object and pack files read-only on the
filesystem is a safety feature to prevent accidental modifications (even
though it's actually not that effective, since brute-force sed
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
I don’t see the issue for the owner of his/her own file to have write
access.
Object and pack files are not meant to be modified. Hence, they are
read-only so that an (accidental) attempt to modify them
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
Hi,
Somehow the “int mode = 0444;” in odb_mkstemp (environment.c) are
causing a lot of issues (unable to unlink/write/rename) to those
people who use AFP shares.
Is it a problem when using Git (like git gc failing to remove old
packs), or
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
I don’t see the issue for the owner of his/her own file to have write
access.
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com writes:
I don’t see the issue for the owner of his/her own file to have write
access.
Object and pack files are not meant
On Feb 17, 2015, at 1:34 PM, Torsten Bögershausen tbo...@web.de wrote:
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
On Feb 17, 2015, at 3:08 AM, Matthieu Moy matthieu@grenoble-inp.fr
wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan fairuzan.ros...@gmail.com
22 matches
Mail list logo
