I deleted a system directory because Carbon Copy Cloner was unable to back it up and suggested replacing it. After deleting and restarting it was rebuilt by the system. However I could not delete the directory from the trash using standard methods or Terminal commands - even logged in as root. Even after disabling System Integrity Protection I had no luck.
Finder says:
The operation can’t be completed because the item “powerlog” is in use.
File was located here:
private>var>db>powerlog>
The directory that was recreated by the system contains subfolders and files but the directory in the trash has none:
sh-3.2# ls -la /Users/admin/Desktop/powerlog
total 0
drwxrwxrwx 3 root wheel 96 Oct 29 16:37 .
drwx------+ 9 admin staff 288 Nov 14 13:18 ..
Attempting rm -R give this result:
sh-3.2# rm -R /Users/admin/.Trash/powerlog
rm: /Users/admin/.Trash/powerlog: Directory not empty
I could not delete it after logging in as root either.
It appears no application is using the folder:
sh-3.2# lsof /Users/admin/.Trash/powerlog
sh-3.2#
Related
I made a simple program in ruby. The file has the shebang at the top and it is executable. When I run it (./parser.rb), it works.
I then created a symlink using ln -s parser.rb refs.
I then moved this symlink to /usr/local/bin. I restarted my terminal and ran refs, this gave me the following message:
zsh: command not found: refs
I cheched my path variable:
jonaseveraert#MacBook-Air-van-Jonas bin % echo $PATH
/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Apple/usr/bin:/Users/jonaseveraert/.cargo/bin
So that seems fine. I then went into the directory /usr/local/bin looked for the file:
jonaseveraert#MacBook-Air-van-Jonas bin % ls -l | grep refs
lrwxr-xr-x# 1 jonaseveraert staff 9 25 jan 14:14 refs.rb -> parser.rb
So, the file is there, but running it inside of the directory gives me:
jonaseveraert#MacBook-Air-van-Jonas bin % ./refs
zsh: no such file or directory: ./refs
Is there anything I'm forgetting here? I can't seem to find an answer to this.
I have found the solution here. The problem was that I made the symlink inside of the same directory as parser.rb and then moved it to /usr/local/bin
When running
jonaseveraert#MacBook-Air-van-Jonas bin % ls -l | grep refs
lrwxr-xr-x# 1 jonaseveraert staff 9 25 jan 14:14 refs.rb -> parser.rb
It shows that refs.rb is pointing to parser.rb in the same directory, but it's parser.rb that isn't there (because it's in another directory).
So, I executed /Users/jonaseveraert/Documents/projects/academic/parser/parser.rb refs inside of /usr/local/bin and now:
jonaseveraert#MacBook-Air-van-Jonas bin % ls -l refs
lrwxr-xr-x 1 jonaseveraert admin 65 25 jan 15:36 refs -> /Users/jonaseveraert/Documents/projects/academic/parser/parser.rb
The file is now pointing to the right file and can be executed using refs.
I can't ls my /Users/alex/Downloads folder.
Other folders work normal.
touch blub.txt works.
via finder I see everything.
Permission are as followed:
613923 0 drwx---r-x# 4 alex staff 128B 29 Jan 22:21 Downloads
I don't understand the behaviour.
I downloaded go1.7.5.darwin-amd64.tar.gz for osx 10.12.2.
Unpacked the tar and went to the /bin directory to see if the Go executable would run.
$ cd Downloads/go/bin
$ ls
total 54560
-rwxr-xr-x# 1 bryanwheelock staff 9884220 Feb 10 16:53 go
-rwxr-xr-x# 1 bryanwheelock staff 15065500 Feb 10 16:53 godoc
-rwxr-xr-x# 1 bryanwheelock staff 2976976 Feb 10 16:53 gofmt
bryanwheelock#Bryans-MacBook Fri Feb 10 16:57:45 ~/Downloads/go/bin
$ go version
-bash: go: command not found
When you type a command without giving the full path, your system will try to find it within all the folders provided in $PATH variable.
In typical Unix environment, your $PATH does not include "your current folder". So you need to either:
call go by its full path (i.e. $HOME/Downloads/go/bin/go); or
call go by its relative path (i.e. ./go); or
put $HOME/Downloads/go/bin in your $PATH variable; or
put . (Unix way of saying "your current folder") in your $PATH; or
put your go binary into folders that already in your $PATH. For example
sudo cp $HOME/Downloads/go/bin/* /usr/local/bin/.
sudo chmod +x go
seems like it does not have execute permission, so just change permission and run it then you should alias your go binary path to your environment to access binary every where.
i'm try to install a libraries but when the make file try to attempt to Developer folder it appear message
Too many levels of symbolic links.
So i try:
Go home folder (cd /)
then i try:
bash-3.2# cd Developer
and this is the output:
bash: cd: Developer: Too many levels of symbolic links
what could be the problem? can you help me?
ls -l
says me
lrwxr-xr-x 1 root wheel 10 14 Mar 09:13 Developer -> /Developer
Use absolute paths when making symlinks:
Doesn't (always) work:
ln -s file ../new/path
Works (more often):
ln -s /full/path/to/old/place/ /full/path/to/new/place/
If go to:
cd /
and ls -la outputs:
lrwxr-xr-x 1 root wheel 10 14 Mar 09:13 Developer -> /Developer
That's a problem. /Developer should be a folder, not a symlink pointing to itself.
Find out where the original /Developer directory is and delete the symlink, so you can create one pointing to it. If you can't find it, consider reinstalling XCode.
For example, I have foo.sh with 770 permissions. When I do:
ln -s foo.sh bar.sh
The link bar.sh has 2777 permissions. Why is this? I thought they were meant to be inherited?
The permissions on a symbolic link are largely immaterial. They are normally 777 as modified by the umask setting.
The POSIX standard for symlink() says:
The values of the file mode bits for the created symbolic link are unspecified. All interfaces specified by POSIX.1-2008 shall behave as if the contents of symbolic links can always be read, except that the value of the file mode bits returned in the st_mode field of the stat structure is unspecified.
POSIX provides an lchown() system call; it does not provide an lchmod() function.
(On my MacOS X 10.7.1, with umask 022, a newly created symlink ends up with 755 permissions; with umask 002, the permissions end up as 775. So, the observation that links are created with 770, 700 etc permissions may be accurate; the permissions settings are still immaterial, and do not affect the usability of the symlink.)
Further investigations about symlinks on RHEL 5 and MacOS X
On Linux (RHEL 5 for x86_64; kernel 2.6.18-128.el5), I only get to see 777 permissions on a symlink when it is created:
$ (ls -l xx.pl; umask 777; ln -s xx.pl pqr; ls -l xx.pl pqr)
-rw-r--r-- 1 jleffler rd 319 2011-09-05 22:10 xx.pl
lrwxrwxrwx 1 jleffler rd 5 2011-09-21 10:16 pqr -> xx.pl
-rw-r--r-- 1 jleffler rd 319 2011-09-05 22:10 xx.pl
$
I ran that in a sub-shell so the umask setting was not permanent.
On MacOS X (10.7.1), I get to see variable permissions on a symlink:
$ (ls -l xxx.sql; umask 777; ln -s xxx.sql pqr; ls -l xxx.sql pqr)
-rw-r--r-- 1 jleffler staff 1916 Jun 9 17:15 xxx.sql
ls: pqr: Permission denied
l--------- 1 jleffler staff 7 Sep 21 10:18 pqr
-rw-r--r-- 1 jleffler staff 1916 Jun 9 17:15 xxx.sql
$
Note that this is the same command sequence (give or take the file name) linked to.
On MacOS X, the chmod command has an option -h to change the permissions on a symlink itself:
-h If the file is a symbolic link, change the mode of the link itself rather than the file that the link points to.
On MacOS X, the permissions on the symlink matter; you can't read the symlink unless you have read permission on the symlink (or you're root). Hence the error in the ls output above. And readlink failed. Etc.
On MacOS X, chmod -h 100 pqr (execute) allows me to use the link (cat pqr works) but not to read the link. By contrast, chmod -h 400 pqr allows me to both read the link and use the link. And for completeness, chmod -h 200 pqr allows me to use the link but not to read it. I assume, without having formally tested, the similar rules apply to group and other.
On MacOS X, then, it seems that read or write permission on a symlink allows you to use it normally, but execute permission alone means you cannot find where the link points (readlink(2) fails) even though you can access the file (or, presumably, directory) at the other end of the link.
Conclusion (subject to modification):
On some versions of Linux, you can only get 777 permission on a symlink.
On MacOS X, you can adjust the permissions on a symlink and these affect who can use the symlink.
The MacOS X behaviour is an extension of the behaviour mandated by POSIX - or deviation from the behaviour mandated by POSIX. It complicates life slightly. It means that you have to ensure that anyone who is supposed to use the link has permission to do so. This is normally trivial (umask 022 means that will be the case).
The underlying system call for chown -h on MacOS X is setattrlist(2).
http://en.wikipedia.org/wiki/Symbolic_link
The file system permissions of a symbolic link usually have relevance
only to rename or removal operations of the link itself, not to the
access modes of the target file which are controlled by the target
file's own permissions.
The permissions for the link are just that. What it points to still has it's own permissions.