I am trying to remove the project directory but receive a Permission denied for .dat.nosyncb77b.* files. What are these files and how can I remove them?
After trying a number of different approaches to solve an Xcode issue with Could not load authors for file 'Pods/Pods.xcodeproj/project.pbxproj' I have tried removing the whole project directory in an attempt to clone the project fresh from git.
However, when running rm -rf project-dir I got Permission denied for .dat.nosyncb77b. files. What is strange is that I am the owner of the files. I have tried changing the permissions to 755 and 775 but no luck. All the other directories and files were successfully removed apart from these .dat.nosyncb77b. files.
None of my other projects have those files. I have cloned the repo again under a different directory and could see that those files do not exist in the same project.xcworkspace/xcuserdata/username.xcuserdatad/ where those files are for that project.
It could be ACLs preventing deletion, these are shown with the e option to ls eg ls -le However I'd put money on the Locked flag being set, as I've encountered the occasional file with the Locked flag.
The easiest way to see this is to perform a Get Info (from Finder) on the files.
In the General Panel and uncheck the Locked checkbox.
It can also be changed on the command line with the command GetFileInfo look at the attributes: line and look for the uppercase L, this means the locked flag is set. It shows as lowercase if unset.
file: "/Users/mark/Documents/20200605-pdftext/test"
type: "\0\0\0\0"
creator: "\0\0\0\0"
attributes: avbstcLinmedz
created: 01/30/2021 14:43:54
modified: 01/30/2021 14:43:54
To change the locked status use SetFile -a l filename
Related
I'm trying to remove all files except read-only ones, but this command removes all of them anyway:
yes n | rm *
Did I do something wrong? If not, why doesn't it work?
For rm to automatically enable -i mode that prompts the user to delete unwritable files, the standard input has to be a terminal (as specified in the man pages).
So, for the command to work correctly the user has to specify the -i option manually:
yes n | rm -i *
After doing so the command works as expected.
In Posix systems, the read-only state of a file does not prevent it from being removed by rm.
You haven't said what your shell is, but perhaps you have an alias to rm that does ask you for confirmation when the file is read-only, and that alias behaves differently when it stdin is part of a pipe.
The problem is you only need write permissions to the folder, not to the files, to remove them:
(From here)
Any attempt to access a file's data requires read permission. Any attempt to modify a file's data requires write permission. Any attempt to execute a file (a program or a script) requires execute permission.
In *nix systems directories are also files and thus use the same permission system as for regular files. Note permissions assigned to a directory are not inherited by the files within that directory.
Because directories are not used in the same way as regular files, the permissions work slightly (but only slightly) differently. An attempt to list the files in a directory requires read permission for the directory, but not on the files within. An attempt to add a file to a directory, delete a file from a directory, or to rename a file, all require write permission for the directory, but (perhaps surprisingly) not for the files within. Execute permission doesn't apply to directories (a directory can't also be a program). But that permission bit is reused for directories for other purposes.
To find files with specific permissions you can use
find -perm <mode>
read more
To remove files found by find you can use
find . -perm 444 -exec /bin/rm {} \;
(mybe slightly different, it depends on files you search and system you have)
more exec examples
I have large projects and some scripts to compile them. I can't add all code here, so I'll try to simplify the problem: in the cleaning part, I need to clean folder named directory which contains other directory named innerDir. I have this bash command for cleaning directory:
clean:
rm -r -f directory
When directory is a folder that I created with mkdir -p beforehand. When I clean, I get this error:
rm: cannot remove 'directory': Directory not empty
But when I try to enter directory , I see that it's empty. So for debugging, I modified my cleanning part to be:
rm -r -f directory/*
find directory
rmdir directory
(it's suppose to do the same, but here I also get the chance to see if all the content of directory was really deleted).
Now I get this error:
find: 'directory/innerDir': Permission denied
There are two things that unclear for me here:
(1). innerDir was created with makedir -p before the clening part, without any change to the permissions of it later in the code. Why don't I have permission to delete it?
(2). If I try to clean again- the cleaning succeed and I don't have any permission problem. So, if I got permission error in the first time I tried to delete it, why don't I get it in the second time?
If your permissions are valid down the directory tree, rm -fr directory ought to work.
If you don't have read access on innerDir, then is it possible/likely (depending on running processes, perhaps) that something has written to innerDir, but the file gets cleaned up after so that the directory becomes free?
Can you give examples of permissions, ownership, and some scope of the operations happening between each step?
Could you rename the parent folder while working, and/or lock it's permissions to prevent other users or processes from altering things?
I am a walking through a tutorial and it lets me delete two directories(im using one 10 deep, all empty) but once i try to remove the third it gives me that error message, even though there is not content in the directory and i am in the directory above it. Why is this? By the way i am using terminal.
That error is reported when the directory is not empty.
To find out what files are in that directory use ls -a. The -a flag tells ls to list hidden files (aka "dot files"). Remove those files then rmdir can be used.
Another option is to simply use rm -rf to recursively delete the directory and all of its files. NOTE: this can be dangerous if you give the wrong parameters - resulting in deleting more than you intended.
you can remove all hidden files by using rm -R ./.* you have to be in the directory the hidden file is in for it to work
On Windows I recently has the same problem, and deleting everything in {UserFolder}\AppData\Local\Composer\files didn't helped.
What I've done is to launch multiple times the composer install --dry-run command until it listed all dependencies, then I successfully ran the composer install command.
I'm trying to write a script that will let me add to an existing directory structure and copy a bunch of files into various places within this. However, using mkdir ... and cp... commands alone wont work since I do not have permission to do so. I understand that this can be changed manually in the 'Get Info' window, but this script will be run by others and its whole point is to save time and hassle.
Is there a way of adding to this script to give me permission to copy files to BASEDIR/SUBDIRS?
A bit more detail on what I'm doing:
I want to add to the directory BASEDIR with a bunch of SUBDIRS then copy files into these subdirectories. The problem is that I am receiving these 'permission denied' errors right after the mkdir BASEDIR/SUBDIR1/SUBDIR2 command.
Thanks
The command
sudo chmod -R ugo=rwx BASEDIR/
gives all folder permissions to all users to BASEDIR and all its subdirectories
For some reason 2 of my files got locked and when I click the little lock icon in the upper right corner of the window it asks me if I would like to unlock, and doing so results in a "The file xxxx.h could not be unlocked" (Unlocking failed for an unknown reason). I have tried to restart Xcode, also tried to restart my machine with no help.
I am also unable to edit the files using BBEdit, I get the error "You do not have sufficient privileges to perform this operation (MacOS Error code: -5000)".
I'm running OS X Lion with Xcode 4.
Very strange as I have not made any changes to my system prior to this problem. Any help would be appreciated.
Open the file in any text editor. If the contents isn't text based you'll see a lot of gibberish. Ignore this, copy the contents. Open up a new text file. Paste the contents and save over the old file. This will copy just the contents of the file and ignore permissions.
What you're dealing with here is an ACL issue. If you ls -l the directory you'll see a little + on the end of the permission string:
drwxr-xr-x+ 4 eekyou staff 136 May 6 2011 eekyou.xcuserdatad
You can easily strip these off like so (in your project directory:
sudo chmod -R -E ./*
Hope this helps.
=]
The #eecue answer didn't help me. I user another Terminal command for complete removal of all ACL permissions:
sudo chmod -RN ./*
First check if the file is opened/locked by another program or user.
If it is not, the program probably crashed and failed to remove the flag, lookup the file and check with CMD+i if it is locked.
If it is not, permissions are probably wrong, so check the permission in the CMD+i dialog at the bottom, and apply them to everything in the enclosing folder (a .xcproject is a directory).
If this still doesn't work (like for me), there is a simple command line to unlock all files in a folder. ONLY do this if all the above steps have been checked / taken.
sudo chflags -R nouchg /Users/username/Development/GIT/MyProject
Replacing the project folder with your own project folder of course.
You may need to take ownership of the folder in which you wish to save your project. To do so, open up the console. Then type sudo chown $USER /path/to/your/project.