"brian m. carlson" 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(...); // give user wri
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
> retur
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio C Hamano 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
Matthieu Moy writes:
> Junio C Hamano 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 compil
Junio C Hamano 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
heard about AF
> On Feb 18, 2015, at 10:05 PM, Matthieu Moy
> wrote:
>
> Fairuzan Roslan 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 th
Fairuzan Roslan 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 is not a Mac OS, it d
> On Feb 18, 2015, at 4:15 PM, Matthieu Moy
> 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 afp "unable to unli
Torsten Bögershausen 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
On 17/02/15 17:58, Fairuzan Roslan wrote:
>
>> On Feb 17, 2015, at 4:51 PM, Matthieu Moy
>> wrote:
>>
>> Fairuzan Roslan writes:
>>
>>> $ git clone https://github.com/robbyrussell/oh-my-zsh.git
>>> Cloning into 'oh-my-zsh'...
>>> remote: Counting objects: 11830, done.
>>> remote: Total 11830 (d
Matthieu Moy 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(...);
> }
> }
I agree wi
> On Feb 17, 2015, at 4:51 PM, Matthieu Moy
> wrote:
>
> Fairuzan Roslan 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: 1
Fairuzan Roslan 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, done.
> Resolving deltas
> On Feb 17, 2015, at 1:34 PM, Torsten Bögershausen wrote:
>
> On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
>>> On Feb 17, 2015, at 3:08 AM, Matthieu Moy
>>> wrote:
>>>
>>> [ Please, don't top post on this list ]
>>>
>>> Fairuzan Roslan writes:
>>>
I don’t see the issue for the owne
On 02/17/2015 04:22 AM, Fairuzan Roslan wrote:
On Feb 17, 2015, at 3:08 AM, Matthieu Moy wrote:
[ Please, don't top post on this list ]
Fairuzan Roslan 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.
> On Feb 17, 2015, at 3:08 AM, Matthieu Moy
> wrote:
>
> [ Please, don't top post on this list ]
>
> Fairuzan Roslan 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-o
On 16.02.15 20:06, Junio C Hamano wrote:
> Matthieu Moy 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" s
[ Please, don't top post on this list ]
Fairuzan Roslan 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 fails.
> Setting tmp id
Matthieu Moy 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 read-only files).
I did no
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 ac
Fairuzan Roslan 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 when trying to remove
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
22 matches
Mail list logo
