I'm executing cypress tests in mounted directory and I want to clean up after myself by deleting the node_modules:
npm uninstall
rm -rf node_modules
However, from time to time I'm getting errors:
rm: cannot remove 'node_modules/.rxjs.DELETE/src/internal/scheduled':
Directory not empty
All files in the volume have the owner nobody:nogroup, so my current user should be able to delete everything. From time to time it's not the case.
What I'm mising? How to correctly clean up after myself?
I have encountered a similar problem before.
Apparently the message you have shown is also caused by files still being used in that directory (I know, misleading... It seems like -rf is just not working).
You mentioning that it works from time to time reinforces my suspicion, things like this are often timing related.
So what you could do is add a sleep 5 or something to test that. The long-term solution should obviously look different... Just make sure, that everything is finished before attempting to clean stuff up.
Related
I am recapping on git in preparation for a project at work and I am falling at the first hurdle when trying to initialise a repo.
I ran the following in GIT BASH (opened as administrator):
cd Users
cd <myuser>
cd Documents
cd git_recap
cd test_project
git init
The last command returns the following error:
C:Users/<myuser>/Documents/git_recap/test_project/.git: No such file or directory
My research tells me that this is a permissions error. I can repeat the exact same steps on my personal computer (not my work one) and it works fine. The problem is that I have no idea which permissions are causing the problem.
I checked the folder permissions for test_project as follows:
cd ..
ls -la
which returns (surmised):
drwxr-xr-x ./
drwxr-xr-x ../
drwxr-xr-x test_project/
I thought: maybe I need to open this folder up for everyone to write to it - fool proof method. I ran:
chmod 777 test_project/
Which returned:
chmod: changing permissions of 'test_project/': Permission denied
I then repeated this process up the folder hierarchy and received the same error message all the way up to the root folder of . I now wanted to see the permissions of all users:
cd ..
ls -la
Which returned:
drwxr-xr-x <myuser>/
To confirm that the issue is with the directory and my permissions within it, I decided to try initialise the repo in the root:
cd <my_user>/
git init
To my surprise, this worked and the repo was succesfully initialised.
Obviously I do not want to initialise my repo here. I want to initialise it in the appropriate test folder.
Any clues what might be wrong and what I might try to correct this?
EDIT
I get identical results when doing the same set of steps from command line (also ran as administrator)
I have stumbled across what I believe is the solution: Windows Security Controlled Folder Access.
This feature is enabled by default on my work laptop and prevents tampering with certain User folders to provide better security in the event of a breach - in particular ransomware.
Unfortunately for me, IT have the power to turn it off - not me.
A little confused at the moment. I've got docker on one my servers and as it doesn't have internet access, I'm trying to build a base image for centos7.4. The nice Docker site has a mkimage_yum.sh script for this purpose, but it consistently fails when it tries running:
yum -c /tmp/mkimage_yum.sh.gnagTv/etc/yum.conf --installroot=/tmp/mkimage_yum.sh.gnagTv -y clean all
with a "No enabled repos" error. The thing is, if I enter "yum repolist" I get back 17 entries, and I have manually tried to set several repos to enabled. Yet, this command still fails, and I do not understand what could be missing.
Anybody have some idea of what I can so this succeeds?
Jay
I figured out why this was failing, the docker file for mkimage_yum.sh does not contain the proper code if you're storing your repos in /etc/yum.repos.d, it assumes that everything is in /etc/yum.conf. This is really not correct, and it causes one of the later yum clean operations to fail. I fixed it, but I cannot upload the change as the server has no internet access.
This folder exists.
I've tried moving it to the trash (it reappears and then this message pops up).
I've reset all permission to all enclosed folders to R+W.
I've repaired permissions on my drive.
Plugging in a real phone works fine (probably not relevant).
Just finished solving this problem. I think the main issue is that you are looking in the wrong place. These are the steps I took:
Make hidden folders visible by going to terminal and executing these two commands:
defaults write com.apple.finder AppleShowAllFiles TRUE
killall Finder
Go to /Users/myUsername/Library now it should be visible ( instead of myUsername you should have yours)
The Logs folder has no access permission, so change it. In case you can't do it manually, go to 3b.
3b. Open terminal. Write this command
sudo chmod 777 ~/Library/Logs
Be happy
P.S. In case you don't want to see hidden folder and files anymore,
execute this two lines in terminal:
defaults write com.apple.finder AppleShowAllFiles FALSE
killall Finder
So your permissions are invalid. You should look in ~/Library/Logs/CoreSimulator and check what the ownership and permissions are set to and fix them.
If that doesn't work, update your question with explanation of what you tried and show the current ownership and permissions on the relevant paths.
Turns out the actual folder for the log file didn't exist.
When looking in Console.app, filtering on CoreSimulator, I saw this:
3/15/15 9:50:52.840 AM iOS Simulator[7291]: Error opening
/Users//Library/Logs/CoreSimulator/iOS Simulator.log
When I went to the Logs directory, CoreSimulator wasn't there, so I:
sudo mkdir CoreSimulator
sudo chown <user>:staff CoreSimulator
touch CoreSimulator/iOS\ Simulator.log
sudo killall -9 com.apple.CoreSimulator.CoreSimulatorService
run this command in terminal before code building.
Cheers!
I have a rails app that I inherited. In deploy.rb, it performs the following commands:
run "mv #{shared_path}/log/#{rails_env}.log #{shared_path}/log/#{rails_env}_old"
run "touch #{shared_path}/log/#{rails_env}.log && chmod -R 777 #{shared_path}/log"
So you can see it's moving the existing log file to one called _old and then creating a new one.
This causes a problem when in some situations, the first deploy fails. When I deploy again, it overwrites the _old file a second time and now the previously existing logs are gone.
The thing is, that I don't understand why the deploy script is doing this. I don't understand why it was written like this in the first place. I believe everybody would be fine if we just left the log files alone during the deploy.
Does anybody have any clues for me?
Remove it, and use log rotate.
What the deploy script is doing is good because log files get big really soon and writing to big file is costly. You should use log rotate or some other utility. But if you want to keep it simple, give unique file names by appending timestamps
run "mv #{shared_path}/log/#{rails_env}.log #{shared_path}/log/#{rails_env}_old_#{Time.now.Time.now.to_i}"
run "touch #{shared_path}/log/#{rails_env}.log && chmod -R 777 #{shared_path}/log"
I have a button in my Preference Bundle for my iOS tweak and I'm trying to have it delete a cache file so that the tweak will work properly.
The function for the button is here
- (void)respring {
system("cd /var/mobile/Library/Caches/com.apple.keyboards");
system("rm -R images");
system("rm version");
}
When I go into iFile afterwords the file is still there and hasn't deleted. Is there a way around this?
I haven't tested this, but my guess is that you are running three separate commands, with system().
So, you run one command to change directory, and then nothing else.
The second command to rm -R images is then run by itself, and not performed with /var/mobile/Library/Caches as the current directory.
You might try simply combining all three commands into one:
system("cd /var/mobile/Library/Caches/com.apple.keyboards; rm -R images; rm version");
If that doesn't work, report back and maybe there's another problem.