Mailinglist Archive: opensuse (6210 mails)
| < Previous | Next > |
Re: [SLE] Konqueror doesn't allow me to delete a file I have full rights to
- From: Shriramana Sharma <samjnaa@xxxxxxxxx>
- Date: Tue, 4 Oct 2005 15:32:55 +0530
- Message-id: <200510041532.56048.samjnaa@xxxxxxxxx>
Wednesday 28 Sep 2005 07:31 samaye Randall R Schulz alekhiit:
> If it really is a FAT file system, then the uid= and gid= in the fstab
> will apply to _all_ files and directories within that mounted file
> system.
Yeah, I found that out.
> As Patrick S. hinted, the ability to delete a file is primarily governed
> by the permissions of the directory in which it resides (to speak
I found that when I changed the permission of both the directory and the file
in question to allow writing (rwx from r-x) I was able to change the filename
and delete the file.
> loosely, since this creates a misunderstanding about the nature of the
> organization and structure of Unix file systems).
In what way?
> In particular, in order to unlink a file (the system call associated
> with the "rm" command) you must have effective permissions to both
> write and execute the directory holding the entry you're trying to
> remove.
Both write and execute? I understand that if you can't open a shelf, you can't
access a file put in that shelf, even if the file by itself is not out of
bounds to you, so the logic of not allowing modification to a file even with
rw attributes so long as its containing directory is r- is understandable.
But why execute?
I also find that it is only necessary that the immediate containing directory
be accessible. /win/d/Transit is r-x to me, but /win/d/Transit/Downloads is
rwx so I can delete the file /win/d/Transit/Downloads/foo.txt which is rwx to
me. How come this is so? Going by the shelf analogy, you cannot access a
shelf which is placed within a locked room, right?
> Lastly, are you sure that the file system is FAT?
Yep.
> misidentifies it) then you cannot modify the file system. There is no
> (non-experimental) NTFS write capability in Linux, so far.
Why is NTFS support in Linux taking so much time to mature whereas FAT support
is full? I mean, it's not as if NTFS was just introduced yesterday?
> If it really is a FAT file system, then the uid= and gid= in the fstab
> will apply to _all_ files and directories within that mounted file
> system.
Yeah, I found that out.
> As Patrick S. hinted, the ability to delete a file is primarily governed
> by the permissions of the directory in which it resides (to speak
I found that when I changed the permission of both the directory and the file
in question to allow writing (rwx from r-x) I was able to change the filename
and delete the file.
> loosely, since this creates a misunderstanding about the nature of the
> organization and structure of Unix file systems).
In what way?
> In particular, in order to unlink a file (the system call associated
> with the "rm" command) you must have effective permissions to both
> write and execute the directory holding the entry you're trying to
> remove.
Both write and execute? I understand that if you can't open a shelf, you can't
access a file put in that shelf, even if the file by itself is not out of
bounds to you, so the logic of not allowing modification to a file even with
rw attributes so long as its containing directory is r- is understandable.
But why execute?
I also find that it is only necessary that the immediate containing directory
be accessible. /win/d/Transit is r-x to me, but /win/d/Transit/Downloads is
rwx so I can delete the file /win/d/Transit/Downloads/foo.txt which is rwx to
me. How come this is so? Going by the shelf analogy, you cannot access a
shelf which is placed within a locked room, right?
> Lastly, are you sure that the file system is FAT?
Yep.
> misidentifies it) then you cannot modify the file system. There is no
> (non-experimental) NTFS write capability in Linux, so far.
Why is NTFS support in Linux taking so much time to mature whereas FAT support
is full? I mean, it's not as if NTFS was just introduced yesterday?
| < Previous | Next > |