Tag Info

New answers tagged

4

In bash, this will delete everything in the current working directory which has the prefix ._: rm ._* If what you actually wanted to do was change their names to a form without the prefix, you can run: ls ._* | while read line do mv -- "$line" "${line:2}" done


3

Assuming you have sufficient permissions to delete the file, simply deleting with the rm command should be sufficient: rm <filename> Note that the size of the file is irrelevant. When you delete a file, it typically isn't wiped in its entirety - instead the inode that points to the disk space is simply marked as unused. The disk space is then ...


6

# rm -rf /path/to/undeletable rm: cannot remove ‘/path/to/undeletable’: Is a directory rm calls stat(2) to check whether /path/to/undeletable is a directory (to be deleted by rmdir(2)) or a file (to be deleted by unlink(2). Since the stat call fails (we'll see why in a minute), rm decides to use unlink, which explains the error message. # rmdir ...


4

You have an NTFS filesystem. In this case you cannot safely fix the problem on anything except a Windows machine. (The Linux code is good, but I cannot recommend you trust it to fix a foreign filesystem.) Take the disk to your Windows system and run CHKDSK /F Q:, or whatever drive letter it's been assigned. Then try deleting the file. If that fails you're ...


0

Refer to Mat's comment. It is time for fsck. The situation you describe is rare. It appears you have at least two inodes pointed to dorothy[1].js + the directory entry for one inode is corrupt + thinks it's pointing to a directory. This should never happen, unless you're using dev/beta code for a filesystem. First run fsck. Then ensure you're running ...


0

Another Linux specific solution would be to use inotify(7) facilities ; you'll detect when files are added, and then you'll immediately run something to remove the older ones. OTOH, I guess that you might have some XY problem. Why do you have so many new files? Perhaps using sqlite, or GDBM indexed files, or some real database (e.g. PostGresQL, MariaDB, ...


0

First thought, I wonder if you might have a trailing space(s) on the file name. Test by typing ls "cifs and then tab to auto-complete (assuming you are on a Linux box, which is a big assumption of course). If this does not bear fruition try removing the file by its inode instead. Good explanation of how to do so here: delete / remove files with inode ...


1

You may still me able to mv that file around it's partition. Try to move it away. But in seems that's disk or filesystem error. Next step I would do is fsck . Also, try 'strace echo "abcd" > file' and find out which syscall really generates the error like "no such file or directory" because if it not exist it should be created, so something else not exist ...


0

Check the output of: find /proc/*/fd -ls | grep '(deleted)' If you find your files listed here, kill the process which has an open file descriptor (or file handle). That should do the trick!


1

Found the answer. Something was wrong with the linkage, as @JeffSchaller suggested. The solution is to run xfs_check to see that the links were incorrect, then xfs_repair to fix them. run mount to view the device name. Mine is /dev/mapper/vg3-lv3 umount /3 xfs_check /dev/mapper/vg3-lv3 which returned the following: link count mismatch for inode ...


-1

You tried to verify that the attributes of the folder / directory have the attribute "i" - imutable is active! Check with the lsattr command to verify that the folder / directory has the attribute "i" activate if you turn it off with "* chattr -i 'folder' *" With this you can perform the task you want.


0

apt-get purge should remove the package as well as all the config. And if you have removed the files with rm there's no way they could still be there. Are perhaps these "files" showing up in /proc? Because in this case you musn't worry, these aren't real files (/proc is just a pseudo filesystem intended to give you an interface on processes and other ...


0

I don't have access to OSX so this is a wild guess... but you can try other techniques to delete files, rather than relying on the shell's globbing to match. Try: find . -not -type d -print -delete or even find . -not -type d -print | perl -nle 'print; unlink'



Top 50 recent answers are included