clone fails: Could not get the current working directory

Howdy,

I'm trying to clone a remote repository.  Here's the background:

- The repository is bare, under Bob's home directory on a remote Sun system.
- Bob has set the group permissions for the repo directory to repogroup.
- I have an account on the remote system that is in repogroup.

I am trying to clone the repo on my home machine, using

 > git clone ssh://john@remote.system.edu/home/bob/path/to/repo

It fails with

remote: fatal: Could not get the current working directory error: git-upload-pack: git-pack-objects died with error. fatal: git-upload-pack: aborting due to possible repository corruption on the remote side. remote: aborting due to possible repository corruption on the remote side. fatal: early EOF fatal: index-pack failed

Checking the source code, this error is triggered after getcwd() returns a null pointer in setup.c:set_work_tree(), which is called at only one place, in setup.c:setup_git_directory_gently().

Can anyone provide any insight as to why am I seeing this error?

Thank you, John

2008/9/21 John Freeman <jfreeman@cs.tamu.edu>:

Do these work:

  $ ssh john@remote.system.edu ls -R /home/bob/path/to/repo
  $ ssh john@remote.system.edu 'cd /home/bob/path/to/repo && pwd'

?

Alex Riesen wrote:

Yes, they do. I wish the mailing list did better threading; please see my other posts if you happened to miss them:

http://article.gmane.org/gmane.comp.version-control.git/96442 http://article.gmane.org/gmane.comp.version-control.git/96505

Thank you, John

2008/9/23 John Freeman <jfreeman@cs.tamu.edu>:

Saw them. .bashrc (/etc/bashrc too) is not used for non-interactive sessions, like yours (of course, you can source them from .profile/.bash_login/.bash_profile).

Have you tried the commands exactly? (Even more interesting would be to try a simple getpwd program which prints errno)

Alex Riesen wrote:

I have. I'm convinced that the problem is not missing commands; if it were, I'd be getting a "missing command," or "file not found," or similar error. Like I've said, I am able to get this to work when the repo is in my home directory. It only fails when the repo is on another path in the system for which I do not have read privileges all the way down - only at the end.

- John

2008/9/23 John Freeman <jfreeman@cs.tamu.edu>:

I actually expected "ls -R" giving error about unable to read the directory (permissions).

Again: try a simple program which just does getpwd for this pathname

Alex Riesen wrote:

This worked.

 From what I gather, getpwd() is in libiberty, which I didn't feel like 
messing with for this example.  I ran a small test program that called 
getcwd() in the repo directory, and it failed.  errno was set to EACCES, 
indicating insufficient permissions.

http://www.opengroup.org/onlinepubs/009695399/functions/getcwd.html

I may get around later to patching this, but for now we're moving ahead with a workaround.

- John

2008/9/23 John Freeman <jfreeman@cs.tamu.edu>:

So there we are...

It suggest a rather dubious workaround (calling pwd).

...but that's a system-inflicted workaround. We just have to do it or something like what it does.

General question: What does Sun's pwd do?

Alex Riesen wrote:

It works like you'd expect. There are no permission problems. Even in directories for which I don't have read access, it will show the path.

- John

2008/9/24 John Freeman <jfreeman@cs.tamu.edu>:

No, not what it shows. What does it call? Which syscalls it uses so we can use them also. Or is /bin/pwd root-SUID?

Paul Johnston wrote:

It is installed in a non-standard directory, /opt/csg/bin. This is part of the system-wide PATH defined in /etc/bashrc. I also added it to my ~/.bashrc before I discovered that fact.

I did create symlinks in $HOME/local/bin which is in the PATH defined in my ~/.bashrc. I do not have administrator privileges, so I cannot put symlinks in /usr/bin. I think it is finding the executable just fine, but that there is some issue with accessing the repo directory. I have tested with

 > ssh user@remote.system.edu -- "git-upload-pack"

and it works as expected.

I've skimmed it, and I see nothing related to my problem. Specifying --upload-pack explicitly gives the same error.

Thank you for the response, though.  Are there any other ideas?

- John

I have also tried copying the repo to my home directory on the remote Sun machine, and then cloning to my local machine. This works as expected.

Does anyone know why a call to getcwd() would fail?

I found this in some documentation on getcwd: http://www.opengroup.org/onlinepubs/009695399/functions/getcwd.html "If a program is operating in a directory where some (grand)parent directory does not permit reading, getcwd() may fail, as in most implementations it must read the directory to determine the name of the file. This can occur if search, but not read, permission is granted in an intermediate directory, or if the program is placed in that directory by some more privileged process (for example, login). Including the [EACCES] error condition makes the reporting of the error consistent and warns the application writer that getcwd() can fail for reasons beyond the control of the application writer or user. Some implementations can avoid this occurrence (for example, by implementing getcwd() using pwd, where pwd is a set-user-root process), thus the error was made optional."

Does anyone know for certain if this is true for Sun machines? Would it be possible to patch / introduce a macro that changes the use of getcwd() to a use of pwd, like the above documentation suggests?

- John