In order to delete the file, you must: * have write access to the file * have write access to the directory * the sTicky bit (chmod +t) must not be set on the directory (sTicky is rare)
-----Original Message----- From: fedora-desktop-list-bounces@redhat.com [mailto:fedora-desktop-list-bounces@redhat.com] On Behalf Of Dotan Cohen Sent: Thursday, March 10, 2005 5:09 PM To: fedora-desktop-list@redhat.com Subject: Being denied my own files!
When trying to delete a file in my /home/dotancohen directory (and logged in as dotancohen) I get:
Access denied to /home/dotancohen/ankush.jpg.
In rightClick-> Properties-> Permissions I saw that Owner can read and write, Group can read, and Others can read. So I changed the permissions so that all the groups say read & write, but still I cannot delete the file. No other application is accessing the file. I'm using Konqueror in KDE on FC3. Thanks in advance.
Dotan Cohen http://English-Lyrics.com http://Song-Lyriks.com
Besides being off-topic (fedora-list would be on-topic for this question), ...
On Thu, 2005-03-10 at 17:12 -0800, Miller, Marc wrote:
In order to delete the file, you must:
- have write access to the file
no. I can delete root-owned files in my directories even if I don't have any rights on the files themselves.
- have write access to the directory
- the sTicky bit (chmod +t) must not be set on the directory (sTicky is
rare)
No. The sticky bit on a directory specifies that contrary to the above only file owners can delete their files, handy for world-writable directories like /tmp and /dev/shm.
Nils
Hi, The magic of Unix inodes:
No user can _actually_ delete a file (Not even root)!
However, If a user can write to a directory (and root can write to any local directory not on a read-only filesystem), then that user can delete the link to the file (i.e. delete the file's name from the directory). If a file's link count (= number of directories the file has a name in) and the number of references (= number of open file descriptors for the file) both go to zero, then the system deallocates the files data blocks and makes the file's inode (which is the unique head of a file) reusable for new files.
Exercise:
% echo "This is the first file" >file1 % ln file1 file2 # Do _not_ put a "-s" here! % ls -li file?
The inode number is the first column - file1 and file2 have the same inode -> they're the same file (just two different names for it - the inode and all data blocks on disk ate the same thing). The link count is the column after the mode bits - it's has the value 2 indicating that the file has two names.
% rm file1 % cat file2
Hmm, look familiar?
Bonus brainteasers: * How many links does "/" have? Why? What are ".." and "."? * What's a symbolic link. * What do "chmod g+s" and "chmod u+s" do to files/directories (This can be fun on Sunos!)
Moles.
no. I can delete root-owned files in my directories even if I don't have any rights on the files themselves.
Strange. I have experienced several times to delete something root-owned (in my home folder) from nautilus -> get thrown to ~/.Trash. (or media/trash, but removable media is usually vfat so permissions isn't an issue)
When i then try to empty trash, all i get is "acess denied".
Kyrre,
On Fri, 11 Mar 2005 21:09:28 +0100, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
Strange. I have experienced several times to delete something root-owned (in my home folder) from nautilus -> get thrown to ~/.Trash. (or media/trash, but removable media is usually vfat so permissions isn't an issue)
When i then try to empty trash, all i get is "acess denied".
If you own a directory, or if you have write permission to it, you can modify all links (file names) within it. If root owns any "normal" file in the dir, you can delete them immediately (rather, "unlink" them - only the system can delete). However, you can't unlink a directory file (yes, at the inode level, everything's a file with a specific type) unless the directory only contains the two links/names "." and ".." ("self inode" and "parent inode"). So it follows from the preceding two paragraphs that if root owns a directory in your home directory (and you can't write to that directory), then you can move it to some other directory (say "~/.trashcan" or something similar), but you can never actually crowbar it out of the filesystem.
In that final case (and if you don't actually have root access to the box you're using), I usually move the directory as far up the filesystem as I can (put it in "/tmp" if it's the same filesystem), rename it to something like "FOR_CLIFFS_SAKE_DELETE_ME" and then possibly send the owner an email requesting it be expunged).
Moles.
søn, 13.03.2005 kl. 13.17 skrev Miles Goodhew:
Kyrre,
On Fri, 11 Mar 2005 21:09:28 +0100, Kyrre Ness Sjobak kyrre@solution-forge.net wrote:
Strange. I have experienced several times to delete something root-owned (in my home folder) from nautilus -> get thrown to ~/.Trash. (or media/trash, but removable media is usually vfat so permissions isn't an issue)
When i then try to empty trash, all i get is "acess denied".
If you own a directory, or if you have write permission to it, you can modify all links (file names) within it. If root owns any "normal" file in the dir, you can delete them immediately (rather, "unlink" them - only the system can delete). However, you can't unlink a directory file (yes, at the inode level, everything's a file with a specific type) unless the directory only contains the two links/names "." and ".." ("self inode" and "parent inode"). So it follows from the preceding two paragraphs that if root owns a directory in your home directory (and you can't write to that directory), then you can move it to some other directory (say "~/.trashcan" or something similar), but you can never actually crowbar it out of the filesystem.
In that final case (and if you don't actually have root access to the box you're using), I usually move the directory as far up the filesystem as I can (put it in "/tmp" if it's the same filesystem), rename it to something like "FOR_CLIFFS_SAKE_DELETE_ME" and then possibly send the owner an email requesting it be expunged).
Okay, i understand :)
Isn't /tmp often flushed by a reboot etc, also?
desktop@lists.fedoraproject.org
-
Kyrre Ness Sjobak -
marc.miller＠amd.com -
Miles Goodhew -
Nils Philippsen