When checking out from the repository with svn co I get the following error after the checkout:
svn: warning: W155010: The node '/path/to/dir' was not found.
svn: E200009: Could not display info for all targets because some targets don't exist
However, the directory exists, and all files are checked out accurately, how can I fix that? Is it a server-side problem?
Just had a similar case. Please make sure you don't have /path/to/dir as a symbolic link in your repo.
ls -l /path/to/
lrwxrwxrwx 1 foo bar 13 Sep 30 13:19 dir -> ../../other_dir
In the above case you should perform svn operations on a real path.
Related
I am working in a CentOS environment and am setting up perlbrew (App::perlbrew/0.87) locally. I've essentially been following the steps here. I have set up perlbrew similarly in the past and no issues, but now am having a strange problem. It is worth noting that I was able to set up perlbrew and install perl locally on the same machine, same environment, for a different user.
The problem is this, perlbrew is installed, but cannot install any version of perl because after downloading the dist it fails to extract the tar.gz.
Here is some information about the install. Perlbrew and cpanm seem to be in place and functioning fine.
-bash-4.1$ env | grep PERL
PERLBREW_SHELLRC_VERSION=0.87
PERLBREW_ROOT=/my/home/dir/perl5/perlbrew
PERLBREW_HOME=/my/home/dir/.perlbrew
-bash-4.1$ env | grep perl
OLDPWD=/my/home/dir/perl5/perlbrew
PERLBREW_ROOT=/my/home/dir/perl5/perlbrew
PATH=/my/home/dir/perl5/perlbrew/bin:/usr/local/bin:/bin:...
PWD=/my/home/dir/perl5/perlbrew/dists
PERLBREW_HOME=/my/home/dir/.perlbrew
-bash-4.1$ which perlbrew
~/perl5/perlbrew/bin/perlbrew
My .bash_profile contains only:
source ~/perl5/perlbrew/etc/bashrc
-bash-4.1$ perlbrew available
perl-5.31.6
perl-5.30.1
perl-5.28.2
perl-5.26.3
perl-5.24.4
...
However, when I try to install, I start getting errors from tar.
-bash-4.1$ perlbrew install perl-5.30.1
tar: perl-5.30.1/.dir-locals.el: Cannot close: Permission denied
tar: perl-5.30.1/.dir-locals.el: Cannot utime: Permission denied
tar: perl-5.30.1/.lgtm.yml: Cannot close: Permission denied
tar: perl-5.30.1/.lgtm.yml: Cannot utime: Permission denied
...
it goes on and on for every file.
I think the key output here is:
Failed to extract /my/home/dir/perl5/perlbrew/dists/perl-5.30.1.tar.gz at /my/home/dir/perl5/perlbrew/bin/perlbrew line 1631
If I navigate to where perlbrew downloads the dist and try to extract it manually, it fails.
-bash-4.1$ cd /my/home/dir/perl5/perlbrew/dists/
-bash-4.1$ ll
total 17308
drwxrwxrwx. 4 myUserID myGroup 11776 Dec 2 15:10 perl-5.30.1
-rwxrwxrwx. 1 myUserID myGroup 17712574 Nov 25 14:46 perl-5.30.1.tar.gz
-bash-4.1$ tar -xvf perl-5.30.1.tar.gz
perl-5.30.1/
perl-5.30.1/.dir-locals.el
tar: perl-5.30.1/.dir-locals.el: Cannot close: Permission denied
tar: perl-5.30.1/.dir-locals.el: Cannot utime: Permission denied
perl-5.30.1/.lgtm.yml
tar: perl-5.30.1/.lgtm.yml: Cannot close: Permission denied
tar: perl-5.30.1/.lgtm.yml: Cannot utime: Permission denied
perl-5.30.1/.metaconf-exclusions.txt
The perl-5.30.1 directory is created and files are made but they are not really extracted. It's just full of 0kb files where everything should be.
I've tested tar by creating tarballs from files I create and zipping and unzipping and whatnot, everything seems to work there fine. All the files are owned by my user/group, so I don't get why I can't extract this file.
Does anyone know what could be the cause of this behavior?
EDIT: This was actually done on a different machine configured the same way as it turns out!
I want to note again that I was able to successfully perform the install on a different user by the same method on the same machine and didn't run into this issue.
One user, #DavidMitchell commented about additional permissions shown by ls -lZ that might influence things. Note that I am using SGE on this machine and have to qlogin to process most tasks.
Before and after qlogins:
In the perl/dist folder before qlogin.
-bash-4.1$ ls -lZ
-rwxrwxrwx. myUser myGroup system_u:object_r:nfs_t:s0 perl-5.30.1.tar.gz
AFTER qlogin
-bash-4.2$ ls -lZ
-rwxrwxrwx myUser MyGroup ? perl-5.30.1.tar.gz
So there's a '?' there, so that's interesting. I checked on another machine and user with successful installation and it seems to show the same thing though, so maybe this isn't the issue. Will continue to look into it further, appreciate any further advice!
I have a valid git repository named /tmp/A.
When I cd to the /tmp/A and run any git command from bash it works good, but when I run git commands from callCommand call in haskell programm I get error:
fatal: Not a git repository: '.'
If I run in callCommand pwd and ls -la before git command, like:
callCommand $ "pwd; ls -la; git status"
It shows that it is at right path /tmp/A and ls shows that repository exists and has .git directory, but git returns error.
What wrong I do?
Upd.
ls output is
drwxrwxr-x 11 xxx xxx 4096 Mar 22 11:44 .
drwxrwxr-x 3 xxx xxx 4096 Mar 22 11:44 ..
drwxrwxr-x 8 xxx xxx 4096 Mar 22 11:44 .git
-rw-rw-r-- 1 xxx xxx 270 Mar 22 11:44 .gitignore
drwxrwxr-x 7 xxx xxx 4096 Mar 22 11:44 dir2
drwxrwxr-x 8 xxx xxx 4096 Mar 22 11:44 dir1
drwxrwxr-x 9 xxx xxx 4096 Mar 22 11:44 test
Upd. Upd.
Program which fails is called from hook post-receive of cloned git repository. When run same program not from hook of this repository, it works fine.
Why self cloning repository from hook does not works?
TL;DR: you probably want unset GIT_DIR at the front of your script (well, however Haskell spells this operation).
The issue here is that while /tmp/A is a sensible Git repository, the actual repository itself is in the .git sub-directory. That is, /tmp/A/ is the work-tree and /tmp/A/.git is the repository proper.
In normal operation, we run git subcommand arguments ..., e.g., git status or git commit -m message from our work-trees. The work-tree contains a .git directory or, in some cases,1 a .git file. The top-level git command checks for .git, finds it, and says aha, the repository is ./.git. Or, it does not find .git, so it looks one level up—e.g., from /tmp/A it would climb one level to /tmp itself, and check there for .git. This repeats until some sort of stopping point.2
In all cases, this search process must either stop successfully—by finding the repository proper—or else git subcommand dies with the fatal: Not a git repository ... message. Now comes the critical, and hidden in plain sight, secret: At this point, the top-level git command sets an environment variable named GIT_DIR to contain the path name of the actual repository. It then runs the sub-command, which uses $GIT_DIR to locate the repository. In our normal use-case, where we are in /tmp/A and /tmp/A contains a .git directory, this sets $GIT_DIR to /tmp/A/.git and the sub-commands all work.
But in your case, $GIT_DIR is already set. Specifially, it's set to .. So now the top-level git command stops searching. It just verifies that $GIT_DIR is valid and names a Git repository, or dies with the fatal error message. Since /tmp/A isn't a repository—it's really /tmp/A/.git—this causes the problem.
Unsetting the environment variable turns the search back on, fixing the problem. You can also use --git-dir as an argument, or set a correct value in $GIT_DIR. Note that the same rules apply with $GIT_WORK_TREE: the --work-tree argument sets $GIT_WORK_TREE, and if you don't use that and $GIT_WORK_TREE isn't set, the front-end git command uses its climb up the file system tree to a .git directory or file code to find the root of your work-tree. So if $GIT_DIR or $GIT_WORK_TREE are set when you run git subcommand, Git obeys them unless you override them with --git-dir and/or --work-tree.
Hooks always have $GIT_DIR set. They may or may not have $GIT_WORK_TREE set as well. Most of them run in the top level of the work-tree, but, as the githooks documentation notes, pre-receive, update, post-receive, post-update, and push-to-checkout all run in $GIT_DIR.
1The .git-as-a-file trick is used by both submodules and added work-trees, in modern Git. Git 1.7 and early 1.8 left submodules with embedded .git directories, and does not support added work-trees.
2The obvious stopping point is upon reaching /, when there is nowhere left to climb. However, Git is by default careful, at least on Unix and Unix-like systems, to avoid climbing through a mount point. Mount points allow you to graft different file system layers and/or storage pools into a single tree-structured hierarchy. Typically /tmp itself might be a memory file system, for instance, and large systems might isolate "system storage" (/ and the like) from "user storage" (/home). Docker uses mount points to restructure file systems in the docker image, and so on.
For the RTOS I'm writing ( http://www.distortos.org ) I need to run find as part of the build configuration process (from make menuconfig target). For Windows I assume that user has MSYS2 installed, so find.exe is available. The only problem with this particular file is that Windows also has such file in C:/Windows/system32 (supposedly it is something close to grep). So depending on the order of folders in your PATH environment variable you get one or the other if trying to call the file by just the name.
I've found that calling this program as /bin/find from the Makefile or in shell script works both in Windows and on (my) Linux. What is most important - doing it that way always calls find.exe from MSYS2, no matter what is the order of folders in PATH. So I'm wondering - is it OK to call find this way, or maybe it is not portable and I just had luck that it works for me?
It would probably be more portable to refer to it as /usr/bin/find. For example, on Fedora /bin is actually a symlink to /usr/bin, so either works:
bash-4.3$ ls -l /bin/find
-rwxr-xr-x. 1 root root 222608 Dec 28 18:26 /bin/find
bash-4.3$ ls -l /usr/bin/find
-rwxr-xr-x. 1 root root 222608 Dec 28 18:26 /usr/bin/find
But on a recent Ubuntu:
root#69ca68fbe5c0:/# ls -l /bin/find
ls: cannot access /bin/find: No such file or directory
root#69ca68fbe5c0:/# ls -l /usr/bin/find
-rwxr-xr-x. 1 root root 229992 Jan 6 2014 /usr/bin/find
I would recommend not hard-coding the path to find and instead instruct Windows users that they must run your script inside the MSYS2 environment. MSYS2 will put its own bin directories near the beginning of the path so that find always gets the MSYS2 version instead of the Microsoft version.
If you hard-code the path to find then you make things be more brittle than they need to be.
I am moving files from my CentOs disk to mounted USB drive as root.
My current working directory is /mnt/hdd/backupmy command is :
mv -v /home/haifzhan/20141215/*gz . > history.log
Error Messages on console:
mv: cannot create regular file `./20141215/filename_xxx.gz': Input/output error
mv: writing `./20141215/filename_yyy.gz': Input/output error
My tracking history log in history.log that create by -v by command mv:
`/home/haifzhan/20141215/filename_xxx.gz' -> `./20141215/filename_xxx.gz'
`/home/haifzhan/20141215/filename_yyy.gz' -> `./20141215/filename_yyy.gz'
The destination folder details:
drwx------. 2 root root 319488 May 13 16:46 20141215
Can anyone help? Thanks!
An "Input/output error" suggests a problem with hardware or filesystem, as indeed proved to be the case here. Upon seeing such an error message it is therefore a good idea to check for more details in the system log, and possibly to run a filesystem integrity check. Such a message does not normally indicate user error.
I would like to clone a git project (from github, say), and have the top level directory be writable by group.
I tried a couple different things. First, just setting the umask before cloning.
$ umask
0002
Files that I create are then writable by group
$ touch test
$ ls -l test
-rw-rw-r-- 1 user group 0 2012-05-17 09:32 test
Now I try git clone
$ git clone git#github.com:user/repo.git
Cloning into repo... [succeeds]
But the clone directory not writable by group.
$ ls -ld repo
drwxr-xr-x 11 user group 4096 2012-05-17 09:32 repo
I tried the same thing with a repo created with git init --shared=umask (which should already be the default) in a directory with 775 permissions. After pushing to github git clone gets the same results.
This isn't a huge deal, I can chmod in my checkout scripts. But if there's a right/builtin way to do this, that's preferable. Git is version 1.7.4.1 on Ubuntu 11.04.
Any ideas or links are appreciated. I saw this post, but it uses chmod, I haven't been able to find much else on this. Thanks!
Try setting the global "core.sharedRepository=group" just for the clone command:
git -c "core.sharedRepository=group" clone git#github.com:user/repo.git
ls -ld repo/.git
drwxrwsr-x 8 user user 4096 Jul 4 22:16 repo/.git/
This was due to a bug, fixed in git >= v1.7.11.3
See:
https://github.com/git/git/commit/45d4fdc2dc74c657a9c2e95bf04aed539fdcb0a4