LinuxQuestions.org
Help answer threads with 0 replies.
Home Forums Tutorials Articles Register
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - General
Reload this Page [SOLVED] Can't delete file(s) in Slackware?
User Name
Password
Linux - General This Linux forum is for general Linux questions and discussion.
If it is Linux Related and doesn't seem to fit in any other forum then this is the place.

Notices


Reply
Page 2 of 2 1 2
  Search this Thread
Old 08-05-2011, 03:04 PM   #16
hopkinskong
LQ Newbie
 
Registered: Aug 2011
Distribution: Ubuntu, Slackware Current
Posts: 10

Original Poster
Rep: Reputation: Disabled

Quote:
Originally Posted by MTK358 View Post
Remember, that will delete every single *.doc file on your system, which is probably not what you want.
Yes, i know that, are the function of "locate" are same as "find"? If i can't find that file i "deleted" using "locate", is that mean i will also can't find that file using "find"?
 
Old 08-05-2011, 03:08 PM   #17
T3RM1NVT0R
Senior Member
 
Registered: Dec 2010
Location: Internet
Distribution: Linux Mint, SLES, CentOS, Red Hat
Posts: 2,385

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
@ Reply
@ hopkinskong,

Yes, that is true that both locate and find commands help you to find files that you are looking for. I would like to mention that with find you can do much more which is not possible with locate command.

find performs a live search whereas locate depends on the database that got create using updatedb command. So, locate command does not perform a live search.

I consider find much more powerful then locate as there are many options that you can use with find that can help you ease and narrow down the search.

@ MTK358,

Yup, I know that is the reason I suggested to run it first with -print and then check and confirm if you OP want to delete them or not. :-)
Last edited by T3RM1NVT0R; 08-05-2011 at 03:10 PM.
 
Old 08-05-2011, 03:27 PM   #18
hopkinskong
LQ Newbie
 
Registered: Aug 2011
Distribution: Ubuntu, Slackware Current
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by T3RM1NVT0R View Post
@ hopkinskong,

Yes, that is true that both locate and find commands help you to find files that you are looking for. I would like to mention that with find you can do much more which is not possible with locate command.

find performs a live search whereas locate depends on the database that got create using updatedb command. So, locate command does not perform a live search.

I consider find much more powerful then locate as there are many options that you can use with find that can help you ease and narrow down the search.

@ MTK358,

Yup, I know that is the reason I suggested to run it first with -print and then check and confirm if you OP want to delete them or not. :-)
I just delete a file using SHIFT+DELETE, no space free out, i try to use find, updatedb+locate, no luck, it output notings, so where are my files?

Thanks.
 
Old 08-05-2011, 05:03 PM   #19
T3RM1NVT0R
Senior Member
 
Registered: Dec 2010
Location: Internet
Distribution: Linux Mint, SLES, CentOS, Red Hat
Posts: 2,385

Rep: Reputation: 477Reputation: 477Reputation: 477Reputation: 477Reputation: 477
@ Reply
Alright. I have to say that it is just not possible.

The only reason that I can think of now is some kind of sync issue which is making your system to think that the file is still there when it is not and your system is reporting free space on the basis of that.

Did you try rebooting your system after deletion of files?

Please paste the output of menu.lst and fstab file.
 
Old 08-05-2011, 08:26 PM   #20
devnull10
Member
 
Registered: Jan 2010
Location: Lancashire
Distribution: Slackware Stable
Posts: 572

Rep: Reputation: 120Reputation: 120
How are you determining free space? Have you tried running the df command and checking the output there?
Also may I suggest using the command line for such tasks.
 
Old 08-06-2011, 12:56 AM   #21
Wim Sturkenboom
Senior Member
 
Registered: Jan 2005
Location: Roodepoort, South Africa
Distribution: Ubuntu 12.04, Antix19.3
Posts: 3,794

Rep: Reputation: 282Reputation: 282Reputation: 282
I think post #19 makes sense and hope that below explains and helps to 'find' the files (that really no longer exist if T3RM1NVT0R and I are right).

You might be able to check if dolphin still has the files 'in use' by using lsof |grep deleted or lsof |grep name_of_known_file.

Code:
wim@desktop-01:~$ sudo lsof |grep deleted
[sudo] password for wim: 
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/wim/.gvfs
      Output information may be incomplete.
mysqld    1556      mysql    4u      REG                8,7        0    1232168 /tmp/ibFj95XR (deleted)
mysqld    1556      mysql    5u      REG                8,7        0    1232169 /tmp/ibJk18Xu (deleted)
mysqld    1556      mysql    6u      REG                8,7        0    1232170 /tmp/ibKb9bY7 (deleted)
mysqld    1556      mysql    7u      REG                8,7        0    1232171 /tmp/ibdRfGYK (deleted)
mysqld    1556      mysql   11u      REG                8,7        0    1232172 /tmp/ibc8mQvo (deleted)
indicator 2177        wim   20r      REG                8,9    39104    1943401 /home/wim/.local/share/gvfs-metadata/home (deleted)
indicator 2177        wim   21r      REG                8,9    32768    1945004 /home/wim/.local/share/gvfs-metadata/home-488c218a.log (deleted)
indicator 2182        wim   20r      REG                8,9    39104    1943401 /home/wim/.local/share/gvfs-metadata/home (deleted)
indicator 2182        wim   21r      REG                8,9    32768    1945004 /home/wim/.local/share/gvfs-metadata/home-488c218a.log (deleted)
gnome-ter 2693        wim   23u      REG                8,7     1891    1232226 /tmp/vteM11JZV (deleted)
gnome-ter 2693        wim   24u      REG                8,7      384    1232228 /tmp/vteUQ1JZV (deleted)
gnome-ter 2693        wim   25u      REG                8,7     1792    1232229 /tmp/vteKS1JZV (deleted)
gnome-ter 2693        wim   26u      REG                8,7    15700    1232230 /tmp/vte5ZBIZV (deleted)
gnome-ter 2693        wim   27u      REG                8,7     2480    1232231 /tmp/vteCOBIZV (deleted)
gnome-ter 2693        wim   28u      REG                8,7    42728    1232232 /tmp/vteBJMJZV (deleted)
gnome-ter 2693        wim   29u      REG                8,7     8192    1232233 /tmp/vteVIMJZV (deleted)
gnome-ter 2693        wim   30u      REG                8,7     6944    1232234 /tmp/vte0CNSZV (deleted)
gnome-ter 2693        wim   31u      REG                8,7      288    1232235 /tmp/vteGXCSZV (deleted)
gnome-ter 2693        wim   32u      REG                8,7      704    1232236 /tmp/vteEDYHZV (deleted)
gnome-ter 2693        wim   33u      REG                8,7      224    1232237 /tmp/vteW9XHZV (deleted)
gnome-ter 2693        wim   34u      REG                8,7      320    1232238 /tmp/vte0Q3HZV (deleted)
wim@desktop-01:~$
All those files are still counted by df (or dolphin).

Below an example of a vi session and what happens; the same might happen when you permanently delete in dolphin. In a terminal I opened a jpg file using vi; this created a swp file. I used a jpg because is has a reasonable size for demonstration.
In another terminal
Code:
wim@desktop-01:~$ ls -al /photos/wim/.IMGP2310.jpg.swp 
-rw-r--r-- 1 wim wim 98304 2011-08-06 07:23 /photos/wim/.IMGP2310.jpg.swp
wim@desktop-01:~$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda7             25806268   5652740  18842628  24% /
none                    507360       336    507024   1% /dev
none                    511896       324    511572   1% /dev/shm
none                    511896       188    511708   1% /var/run
none                    511896         0    511896   0% /var/lock
none                    511896         0    511896   0% /lib/init/rw
/dev/sda9            120120516  22425524  91593132  20% /home
/dev/sdb1            969063944 143126256 816170088  15% /photos
wim@desktop-01:~$ lsof |grep IMGP
vi        3500        wim    4u      REG               8,17    98304   42344454 /photos/wim/.IMGP2310.jpg.swp
wim@desktop-01:~$ rm /photos/wim/.IMGP2310.jpg.swp 
wim@desktop-01:~$ lsof |grep IMGP
vi        3500        wim    4u      REG               8,17    98304   42344454 /photos/wim/.IMGP2310.jpg.swp (deleted)
wim@desktop-01:~$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda7             25806268   5652740  18842628  24% /
none                    507360       336    507024   1% /dev
none                    511896       324    511572   1% /dev/shm
none                    511896       188    511708   1% /var/run
none                    511896         0    511896   0% /var/lock
none                    511896         0    511896   0% /lib/init/rw
/dev/sda9            120120516  22425524  91593132  20% /home
/dev/sdb1            969063944 143126256 816170088  15% /photos
wim@desktop-01:~$
After the 'rm' (simulating your permanent delete in dolphin), there was no change in the result of 'df -k'

Once I ended the vi session in the first terminal, the 100kBytes were released again.
Code:
wim@desktop-01:~$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda7             25806268   5652740  18842628  24% /
none                    507360       336    507024   1% /dev
none                    511896       324    511572   1% /dev/shm
none                    511896       188    511708   1% /var/run
none                    511896         0    511896   0% /var/lock
none                    511896         0    511896   0% /lib/init/rw
/dev/sda9            120120516  22425524  91593132  20% /home
/dev/sdb1            969063944 143126156 816170188  15% /photos
wim@desktop-01:~$
Note:
there have been a couple of questions about 'du' and 'df' reporting different 'free space'. I did the same exercise using 'du'
Code:
wim@desktop-01:~$ du -k --max-depth=1 /photos/wim/
33120	/photos/wim/
wim@desktop-01:~$ rm /photos/wim/.IMGP2310.jpg.swp 
wim@desktop-01:~$ du -k --max-depth=1 /photos/wim/
33020	/photos/wim/
wim@desktop-01:~$
'du' straight away reported the 'new' size' after I deleted the swp file
Last edited by Wim Sturkenboom; 08-06-2011 at 01:05 AM.
 
Old 08-06-2011, 06:57 AM   #22
hopkinskong
LQ Newbie
 
Registered: Aug 2011
Distribution: Ubuntu, Slackware Current
Posts: 10

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by Wim Sturkenboom View Post
I think post #19 makes sense and hope that below explains and helps to 'find' the files (that really no longer exist if T3RM1NVT0R and I are right).

You might be able to check if dolphin still has the files 'in use' by using lsof |grep deleted or lsof |grep name_of_known_file.

Code:
wim@desktop-01:~$ sudo lsof |grep deleted
[sudo] password for wim: 
lsof: WARNING: can't stat() fuse.gvfs-fuse-daemon file system /home/wim/.gvfs
      Output information may be incomplete.
mysqld    1556      mysql    4u      REG                8,7        0    1232168 /tmp/ibFj95XR (deleted)
mysqld    1556      mysql    5u      REG                8,7        0    1232169 /tmp/ibJk18Xu (deleted)
mysqld    1556      mysql    6u      REG                8,7        0    1232170 /tmp/ibKb9bY7 (deleted)
mysqld    1556      mysql    7u      REG                8,7        0    1232171 /tmp/ibdRfGYK (deleted)
mysqld    1556      mysql   11u      REG                8,7        0    1232172 /tmp/ibc8mQvo (deleted)
indicator 2177        wim   20r      REG                8,9    39104    1943401 /home/wim/.local/share/gvfs-metadata/home (deleted)
indicator 2177        wim   21r      REG                8,9    32768    1945004 /home/wim/.local/share/gvfs-metadata/home-488c218a.log (deleted)
indicator 2182        wim   20r      REG                8,9    39104    1943401 /home/wim/.local/share/gvfs-metadata/home (deleted)
indicator 2182        wim   21r      REG                8,9    32768    1945004 /home/wim/.local/share/gvfs-metadata/home-488c218a.log (deleted)
gnome-ter 2693        wim   23u      REG                8,7     1891    1232226 /tmp/vteM11JZV (deleted)
gnome-ter 2693        wim   24u      REG                8,7      384    1232228 /tmp/vteUQ1JZV (deleted)
gnome-ter 2693        wim   25u      REG                8,7     1792    1232229 /tmp/vteKS1JZV (deleted)
gnome-ter 2693        wim   26u      REG                8,7    15700    1232230 /tmp/vte5ZBIZV (deleted)
gnome-ter 2693        wim   27u      REG                8,7     2480    1232231 /tmp/vteCOBIZV (deleted)
gnome-ter 2693        wim   28u      REG                8,7    42728    1232232 /tmp/vteBJMJZV (deleted)
gnome-ter 2693        wim   29u      REG                8,7     8192    1232233 /tmp/vteVIMJZV (deleted)
gnome-ter 2693        wim   30u      REG                8,7     6944    1232234 /tmp/vte0CNSZV (deleted)
gnome-ter 2693        wim   31u      REG                8,7      288    1232235 /tmp/vteGXCSZV (deleted)
gnome-ter 2693        wim   32u      REG                8,7      704    1232236 /tmp/vteEDYHZV (deleted)
gnome-ter 2693        wim   33u      REG                8,7      224    1232237 /tmp/vteW9XHZV (deleted)
gnome-ter 2693        wim   34u      REG                8,7      320    1232238 /tmp/vte0Q3HZV (deleted)
wim@desktop-01:~$
All those files are still counted by df (or dolphin).

Below an example of a vi session and what happens; the same might happen when you permanently delete in dolphin. In a terminal I opened a jpg file using vi; this created a swp file. I used a jpg because is has a reasonable size for demonstration.
In another terminal
Code:
wim@desktop-01:~$ ls -al /photos/wim/.IMGP2310.jpg.swp 
-rw-r--r-- 1 wim wim 98304 2011-08-06 07:23 /photos/wim/.IMGP2310.jpg.swp
wim@desktop-01:~$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda7             25806268   5652740  18842628  24% /
none                    507360       336    507024   1% /dev
none                    511896       324    511572   1% /dev/shm
none                    511896       188    511708   1% /var/run
none                    511896         0    511896   0% /var/lock
none                    511896         0    511896   0% /lib/init/rw
/dev/sda9            120120516  22425524  91593132  20% /home
/dev/sdb1            969063944 143126256 816170088  15% /photos
wim@desktop-01:~$ lsof |grep IMGP
vi        3500        wim    4u      REG               8,17    98304   42344454 /photos/wim/.IMGP2310.jpg.swp
wim@desktop-01:~$ rm /photos/wim/.IMGP2310.jpg.swp 
wim@desktop-01:~$ lsof |grep IMGP
vi        3500        wim    4u      REG               8,17    98304   42344454 /photos/wim/.IMGP2310.jpg.swp (deleted)
wim@desktop-01:~$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda7             25806268   5652740  18842628  24% /
none                    507360       336    507024   1% /dev
none                    511896       324    511572   1% /dev/shm
none                    511896       188    511708   1% /var/run
none                    511896         0    511896   0% /var/lock
none                    511896         0    511896   0% /lib/init/rw
/dev/sda9            120120516  22425524  91593132  20% /home
/dev/sdb1            969063944 143126256 816170088  15% /photos
wim@desktop-01:~$
After the 'rm' (simulating your permanent delete in dolphin), there was no change in the result of 'df -k'

Once I ended the vi session in the first terminal, the 100kBytes were released again.
Code:
wim@desktop-01:~$ df -k
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda7             25806268   5652740  18842628  24% /
none                    507360       336    507024   1% /dev
none                    511896       324    511572   1% /dev/shm
none                    511896       188    511708   1% /var/run
none                    511896         0    511896   0% /var/lock
none                    511896         0    511896   0% /lib/init/rw
/dev/sda9            120120516  22425524  91593132  20% /home
/dev/sdb1            969063944 143126156 816170188  15% /photos
wim@desktop-01:~$
Note:
there have been a couple of questions about 'du' and 'df' reporting different 'free space'. I did the same exercise using 'du'
Code:
wim@desktop-01:~$ du -k --max-depth=1 /photos/wim/
33120	/photos/wim/
wim@desktop-01:~$ rm /photos/wim/.IMGP2310.jpg.swp 
wim@desktop-01:~$ du -k --max-depth=1 /photos/wim/
33020	/photos/wim/
wim@desktop-01:~$
'du' straight away reported the 'new' size' after I deleted the swp file
Thanks for help, i don't know why it working again lol, but i remembered that i deleted 30 MB boot file it doesn't release the space, now i tried create a zero file(/dev/zero), it worked again lol

May be it should some kind of log problem, cuz i compiled the kernel with lots of debug mode, maybe when i deleted boot it created lots of log rapidly
Last edited by hopkinskong; 08-06-2011 at 06:58 AM.
 
  


Reply
Page 2 of 2 1 2



Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Create the file, write into that file but can't delete file in Linux pandunr Linux - Newbie 3 06-15-2011 08:45 AM
file from install ffmpeg conflicts w/file from package fmpeg-libs: which to delete? ybalazs Linux - Software 0 10-27-2009 01:21 AM
Upload file to ftp server -vsftp- but can not delete or change the file once uploaded murattas6 Linux - Server 2 06-26-2009 06:00 AM
Tried to delete file as root but it says I don't have permission to delete it! beejayzed Mandriva 23 03-12-2004 02:46 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - General

All times are GMT -5. The time now is 03:48 PM.

Contact Us - Advertising Info - Rules - Privacy - LQ Merchandise - Donations - Contributing Member - LQ Sitemap -
Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration