Undeletable file in cygwin - cygwin

A command I executed in cygwin hosed up a bunch of files. Now I cannot delete them. Omitting most of the 'ls' output, here is what I'm dealing with:
% ls -l
ls: cannot access WSERV001.txt: No such file or directory
-rw-r--r-- 1 mccppk mkgroup-l-d 50 Sep 17 16:57 WSERV001.text
??????????? ? ? ? ? ? WSERV001.txt
% rm WSERV001.txt
rm: cannot remove `WSERV001.txt': No such file or directory
% touch WSERV001.txt
touch: cannot touch `WSERV001.txt': Permission denied
The .text file is normal. The .txt file (directory entry anyway) is obviously hosed. Any ideas on how to get the .txt file deleted?

I had the same problem and fixed it as follow (under Win7):
Open a cmd windows (run as Administrator)
takeown /r /f DRIVE:\PATH
icacls DRIVE:\PATH /grant USERNAME:F /T
where USERNAME is your win7 username under which you are running this.
Also make sure cron.exe is NOT running for user USERNAME or SYSTEM (can be checked from the TaskManager) and that no programs from cygwin are running.
Once all has been checked and done, you should be able to delete your files.
Hope this helps,
Jean

I have a reproducible case and none of what is suggested here helps because of permissions restrictions.
Under sygwin:
[Sakis#t0000000000]$ ll
total 0
drwxr-x--- 1 ???????? ???????? 0 Jul 4 02:51 t0000000000_1.db/
[Sakis#t0000000000]$
Trying to take the owner from an admin cmd console:
c:\t000000000
0>takeown /r /f t0000000000_1.db
ERROR: Access is denied.
Trying to delete from an admin cmd console:
c:\t000000000
0>rmdir /S t0000000000_1.db
t0000000000_1.db, Are you sure (Y/N)? Y
Access is denied.
Cannot also change the owner from the windows GUI. It complains that you should have read permissions.
--- RESOLVED ---
Finally, I have managed to delete it by entering a cmd command with administration privileges and execute:
rm -r <dir>
TIP: You have to make sure that the directory in not used at all. You can use the procmon to find you who locks that directory.

Attempts to use chown and chmod, even as root, failed (I don't recall the error).
I'm pretty sure my disk is fine. I run DiskCheckup daily for a strong history of SMART settings, and checked it this morning. No worries there.
Since the original problem and post, I got busy, and just now got back to that same local shell window. Those files were gone. This was a local cygwin shell on my laptop, so I know that no one else "helped". Strange. Those .txt files were just not there anymore.
I'm still curious what would cause ls to output all question-marks like that for all of the file metadata, except for the filename. But the main issue is resolved.

As admin, this should fix:
chown <yourusername> WSERV001.txt
chmod 666 WSERV001.txt
rm -f WSERV001.txt
If not, you might have disk errors.

Related

change permissions on a not writable

UPDATE:
I moved my question to ask ubuntu community, but can not delete it from here... if you have an awenser, please share it on ubuntu community not here... Thanks
i want to make an change on a file but i cant do that because i have not correct permissions:
➜ ls -l pycharm64.vmoptions
-rw-r--r-- 1 root root 427 Dec 28 18:33 pycharm64.vmoptions
i tried to change permisions by these two command:
sudo chmod a+w pycharm64.vmoptions
and
sudo chown user:user pycharm64.vmoptions
but in i get an erro both time:
Read-only file system
how can i make an change on my file? (honestly i dont care about the owner and groups of the file... i just want to change my file anyway)
P.S: my OS is UBUNTU
You can change a file on read only by setting the "immutable property"
chattr +i [fileName]
If you want to revert it just change the "+" for a "-"
chattr -i [fileName]
Your filesystem could be mounted as read only. You have to change first before you can write anything to it. Changing file permissions also requires writing on the filesystem.
You may be able to mount it as read write with command like:
sudo mount -o remount,rw /dev/foo /mount/destination/dir
In this command you spesify that you want to remount the filesystem with different options, adding the readwrite, rw capability.
If you successd in changing the filesystem to read write, then you should be able to change to file permissions with the commands you tried earlier.
You can`t edit it directly (I'm not sure about Windows).
You should edit custom settings file instead:
Manually
nano ~/.config/JetBrains/PyCharm2022.3/pycharm64.vmoptions
or from IDE -- https://intellij-support.jetbrains.com/hc/en-us/articles/206544869.

zsh compinit: insecure directories. Compaudit shows /tmp directory

I'm running zsh on a Raspberry Pi 2 (Raspbian Jessie). zsh compinit is complaining about the /tmp directory being insecure. So, I checked the permissions on the directory:
$ compaudit
There are insecure directories:
/tmp
$ ls -ld /tmp
drwxrwxrwt 13 root root 16384 Apr 10 11:17 /tmp
Apparently anyone can do anything in the /tmp directory. Which makes sense, given it's purpose. So I tried the suggestions on this stackoverflow question. I also tried similar suggestions on other sites. Specifiacally, it suggests turning off group write permissions on that directory. Because of how the permissions looked according to ls -ld, I had to turn off the 'all' write permissions as well. So:
$ sudo su
% chmod g-w /tmp
% chmod a-w /tmp
% exit
$ compaudit
# nothing shows up, zsh is happy
This shut zsh up. However, other programs started to break. For example, gnome-terminal would crash whenever I typed the letter 'l'. Because of this, I had to turn the write permissions back on, and just run compinit -u in my .zshrc.
What I want to know: is there any better way to fix this? I'm not sure that it's a great idea to let compinit use an insecure directory. My dotfiles repo is hosted here, and the file where I now run compinit -u is here.
First, the original permissions on /tmp were correct. Make sure you've restored them correctly: ls -ld /tmp must start with drwxrwxrwt. You can use sudo chmod 1777 /tmp to set the correct permissions. /tmp is supposed to be writable by everyone, and any other permissions is highly likely to break stuff.
compaudit complains about directories in fpath, so one of the directories in your fpath is of the form /tmp/… (not necessarily /tmp itself). Check how fpath is being set. Normally the directories in fpath should be only subdirectories of the zsh installation directory, and places in your home directory. A subdirectory of /tmp wouldn't get in there without something unusual on your part.
If you can't find out where the stray directory is added to fpath, run zsh -x 2>zsh-x.log, and look for fpath in the trace file zsh-x.log.
It can be safe to use a directory under /tmp, but only if you created it securely. The permissions on /tmp allow anybody to create files, but users can only remove or rename their own files (that's what the t at the end of the permissions means). So if a directory is created safely (e.g. with mktemp -d), it's safe to use it in fpath. compaudit isn't sophisticated enough to recognize this case, and in any case it wouldn't have enough information since whether the directory is safe depends on how it was created.

Does Cygwin lock out chmod changes for system user?

Similar to this question, I am unable to unset execute permissions on files after recently upgrading Cygwin.
I have a file with the following permissions:
ls -l filename
-rw-rwxr--+ 1 gstrycker Users 1334935 Jan 26 09:23 filename
I'm trying to get rid of execute privileges, but running chmod -x or even chmod 0 does not seem to work now (note that it always did work for me before -- but I don't believe there were this many columns in the POSIX security permissions)
chmod 0 filename
ls -l filename
----rwx---+ 1 gstrycker Users 1334935 Jan 26 09:23 filename
Why can I not seem to be able to modify this central group of privileges now? I've always been able to before. I even tried to change the group owner, but that didn't seem to help.
I'm stuck -- any ideas? Is this a new Cygwin bug? Did Cygwin recently add columns to the POSIX permissions, and if so, how do I access these?

ant Permission Denied problem

After extracting and saving the ant files into an opt/ directory and setting the path variable
to $ANT_HOME/bin
I ran the following command on a CentOS 5
ant -version
and I am getting the following error
-bash:/path/opt/apache-ant-1.8.2/bin/ant: Permission denied
Is there some permission I am supposed to set or some typical source of this problem?
Thanks!
If you own the file, try
chmod u+x /path/opt/apache-ant-1.8.2/bin/ant
If someone else owns it, either sudo or become root then
chmod 755 /path/opt/apache-ant-1.8.2/bin/ant
You need to have execute permissions on the file; the first gives execute permissions to the owner only and is probably preferable if you own the file and are the only one that uses it. The second requires root privileges and gives execute and read permission to everyone, plus write permission to the owner.
You can view the current permissions and ownership of the file by running ls -l /path/opt/apache-ant-1.8.2/bin/ant.

Getting error that the database is locked when refreshing the page

I am running apache with mod mono and my asp.net app is using mono sqlite as its db. When i refresh the page twice i get the DB is locked error. The folder it is in is chmod 777. The webapp is creating sqlite.db and sqlite.db-journal but it doesnt seem to be able to delete the journal. Also it has problems when i load the page once. It definitely seems to be a permission problem.
i'm confused. What permissions do i need to set these? i tried precreating the files using 777 and had no luck.
-edit- I didnt find a solution however i thought how silly i was being since i was planning to use mysql for my webapp. So i just ported the code and i no longer had issues.
When creating/deleting a file the directory permission matter.
So, if you really want that, you have to set the containing directory's permissions to 777.
Sample:
$ ls -la
total 21
dr-xr-xr-x 2 me me 1024 May 22 19:19 . #no write permissions to directory
drwxrwxrwt 21 root root 19456 May 22 19:19 ..
-rwxrwxrwx 1 me me 0 May 22 19:19 abc #all permissions to file abc
$ rm abc
rm: cannot remove `abc': Permission denied #abc has 777, but deleting doesn't work
$ chmod 777 . #change directoy's permissions
$ rm abc #now removing works
$ ls #file abc is gone
The reason is that when you delete a file, you actually modify the directory and not the file itself.
Think of a hard link: The file itself will not change when you delete one hardlink to it, but the directory changes.
Sounds more like one instance of the session in apache is blocking the other session, i.e. has the db file open exclusively. Try to let the database(model) run as a singleton (or similar) which all sessions access.

Resources