Somehow, my system (Ubuntu WSL layer on Windows; so treat as exactly Ubuntu) went a bit crazy. For a directory (a git repo if it matters) /path/to/foo, running ls shows the git files ORIG_HEAD, index, and index.lock in there.
I tried to debug this by going cd .git, but an ls there showed me my same list of files as the parent!
I went as far as
/path/to/foo/.git/.git/.git
before stopping checking the recursion.
A possibly related issue that managed to show up is that the .htaccess file there is read as a file by Emacs on Windows, a file by vi on Linux, but a directory by emacs and a directory by bash.
That means that my computer really thinks
~/public_html/.git/.htaccess/.htaccess/.git/.htaccess/.git/.git
is identical to
~/public_html
So, needless to say, Apache also craps out and says that it's an invalid htaccess file .... though on an other machine (see: git repo) it runs just fine.
Help?
Tried nuking the directory via rm -rf and git clone-ing back, but the Apache problem persisted.
I removed the symlink to the directory via unlink:
~$ unlink public_html
then re-mounted it, making sure that there wasn't a trailing space
~$ ln -s /mnt/c/Users/USER/pathto/repo /home/USER/public_html
Related
I don't know if what I encountered was a bug or is intended behavior, but luckily I figured out pretty quick what was going on.
I had my shell cd'd inside a subdirectory of the git repo, and I performed a git rebase -i squash operation in which the commits involved included the creation of this directory.
After that operation completed without incident, the shell became in an orphaned state where the git status (neither in the zsh theme helper RPROMPT nor when run) indicated that I wasn't even in a git repository anymore.
Once I ran cd .. everything was fine, and it all made sense. During the course of the rebasing operation, Git had rm'd the directory that I was in (at the first step of the rebase) and subsequently put it back. Since it got put back, I could also have ran cd $(pwd) to go there in one step.
This is some confusing behavior. Although, it is not clear that anything was technically done wrong by git. My question is would this be a bug in git or should users be expected to know how to deal with this situation?
Also, the wider, actual root question: Why is it permitted to remove a directory that my shell is in, when it is not permitted to eject a disk if I have a shell on a mounted directory? It seems inconsistent to me.
Case in point: fuser <directory> shows current directory uses. If a program is "on" a directory it is "using" it.
Terminal 1:
$ cd tmp/
$ mkdir test
$ cd test
Terminal 2:
$ rmdir tmp/test
Terminal 1:
$ ls
sh: 0: getcwd() failed: No such file or directory
Inconsistent, yes. But allowed.
PS. And this has nothing to do with git.
To answer your first question:
It is not a bug, it is how Unix systems, including Linux, have always worked.
There's even some nice text in the POSIX spec:
[EBUSY] The directory to be removed is currently in use by the system or some process and the implementation considers this to be an error.
Namely, some implementation (e.g. Windows...) can call it an error, but most implementations. namely Unix variants, do not.
The way this is implemented in a filesystem is by having the processes hold a reference on the object which represents the directory. Another thing that holds such a reference is the parent directory. git rebase has removed the latter reference, but the former remains. Even if the directory is re-created, it is a new filesystem object, whereas your shell was holding a reference to the old object.
That's why cd .. and cd $(pwd) still work - they re-lookup the directory and grab the new reference, and release the old reference.
Officially the old object is not cleaned up until the old reference is released. That means that the metadata of the directory is not removed from the disk until the process releases the old working directory.
To answer your second question:
In order to eject a drive you have to unmount the mountpoint, and as above, the processes you find with fuser hold references to that mountpoint.
As with directory references, a amount point cannot be cleaned up until all references to it have been removed. That is why you cannot eject a drive which has references.
The consistent thing to do would be to allow detaching the filesystem from the directory tree without actually cleaning up. You still won't be able to eject the drive, but at least you can use the directory tree as you wish.
Well, that is actually possible to do with umount --lazy.
Over the weekend I had to performed a fresh install on Ubuntu on my laptop.
I was restoring my files from my backup, but I used the wrong username.
I've tried to change the username and the $PATH but I'm still getting the same error
t0m#asuntu:~$ wget -qO- https://raw.githubusercontent.com/creationix/nvm/v0.33.8/install.sh | bash
=> Downloading nvm from git to '/home/ubut0m/.nvm'
=> mkdir: cannot create directory ‘/home/ubut0m’: Permission denied
ls: cannot access '/home/ubut0m/.nvm': No such file or directory
fatal: could not create leading directories of '/home/ubut0m/.nvm': Permission denied
Failed to clone nvm repo. Please report this!
t0m#asuntu:~$ vim .bashrc
t0m#asuntu:~$
I've tried removing and reinstalling everthing (NPM, Node, NVM), but don't know why I can't get the script to work. Any help is appreciated.
Check that you're $HOME environment variable matches that of the user you are currently running as, which you can check with whoami. Sometimes, some tools that elevate privileges (such as sudo) preserve the old user's home directory environment variable while running as the new user.
If that's not the problem, check that your home directory exists and has the correct permissions. Usually, if that's the problem, all sorts of other issues pop up (but I can understand a tendency to ignore such things on a newly restored machine).
If it's neither of those things, you can try making sure that you are in your home directory when running the wget | bash command although that really shouldn't be necessary (and if that turns out to be the issue, I would definitely file a bug with nvm about it).
I am a windows developer switching over to OSX. I am very confused though. I am learning node.js and the documentation tells me to add a reference to nodemon at the path...
/usr/local/bin/nodemon
However when I am at the terminal and I type 'ls' I get the following output...
And that doesn't have a /usr/ folder ... And what is even more confusing is that if I do...
ls -a
Then I can see all my hidden folder with a folder in called .npm which seems to have all my modules. In windows this is easy it just installs all npm modules into %AppData%/npm or something but I just don't get it on OSX can somebody enlighten me please?
ls lists the directories and files in your current working directory.
You can find your current working directory with pwd (short for 'print working directory')
You can change your current working directory with the cd (change directory) command. In your case, you could run
cd /usr/local
ls
and it would show you the bin directory. Alternatively, you could directly run
ls /usr/local
As a special extra note, the Terminal Prompt itself actually displays the current working directory (by default). In your case, it shows ~, which is shorthand for the user profile directory, which the Terminal opens to automatically. It is generally /Users/<username>.
I am on Fedora 17 trying to use svn version 1.7.6
I have created a repository at /home/el/svnworkspace and I checked out a working copy in /workspace
I am getting this error when I use the command:
[root#defiant workspace]# svn remove TestProject --force
Gives the Error:
svn: E155035: '/workspace/TestProject'
is the root of a working copy and cannot be deleted
The error message is partially right, TestProject was a root before. But I deleted it and now /workspace the root. So somehow it is confused. I no longer want TestProject to be a root, and I want workspace to be the root. svn is confused, and I want to unconfuse it, maybe one of you know the proper wizard incantation to remove /workspace/TestProject as a root of a working copy? I just want it to be a normal folder again.
Perhaps the only way for me to fix it is to blow everything away and re-add everything. Maybe a resident wizard knows a better way.
SVN does get confused about directories sometimes.
Unless you have a lot of changes you need to check in, I suggest removing the hierarchy in question from your filesystem (rm -rf), and checking out again starting from wherever looks appropriate. This always seems to handle SVN directory confusion for me.
I was able to fix the problem with these steps:
Make sure nothing has a lock on the files in question, for me: Eclipse IDE. So close any IDE's or Editors that might have a lock on the file.
Make sure you have write permissions on the working copy as well as the repository.
chmod -R 775 /workspace
chown -R your_user_name.your_user_name 775 /workspace
chmod -R 775 /home/el/svnworkspace
chown -R your_user_name.your_user_name 775 /home/el/svnworkspace
If you are using a program with a GUI like rapidsvn to add/remove/commit files, turn that off and use only the command line svn command. The GUI might have been have been conflicting with what I was trying to do on the command line.
finally, I think this part is what fixed my problem:
Go into the directory that I want to add, but won't add. Manually rm -rf all the .svn files in it. Then try to svn remove it then svn add it. It successfully adds and then I could commit it and all is well.
I have gitweb on localhost and a sample project for which I've executed the git init git add and so on. I create a symlink with sudo ln -s /media/dir/project/.git/ /var/cache/git/project.git but it doesn't work and I still get 404 - no project found at localhost/gitweb.
The only way I can only bring the project info titles such as description, ..., then without project info, only the 4 sorting options, is to copy the git physically to /var/cache/git/project.git/ though some files won't be copied. This is the only way I could only not receive the not found error.
I manipulated the /etc/gitweb.conf and /etc/apache2/conf.d/gitweb in anyway, but it didn't help.
(I'm using apache 2.2 under Kubuntu 11.10)
Thanks so much for your helps!
Check the permissions on all of the directories in the symlink path. Whatever user your cgi is running as needs at least +x on all the parent dirs and +r on the .git directory and files.