David Faure wrote:
> 
> > David misunderstood me :)
> :)
> 
> This starts to be a discussion, let's use mail :-)
> 
> > ... My concern was more that the fact we can list / doesn't mean we can
> >  remove it. So we shouldn't remove everything we could list without
> checking
> >  we can. But then the question arises how do we check we can remove it?
> I see. Hmmm.
> I guess we'll end up opening the sources of rm :-)
> 
> "rm -rf /" does not list everything recursively and then abort in the
> middle. I guess this is because it simply checks the permissions on whatever
> we're trying to remove (here "/") FIRST.
> 
> And if you 'rm -rf ~/tmp' which you own, and if in ~/tmp there is something
> you can't delete, it will start (no permissions problems on the target,
> ~/tmp),
> then remove everything else, and abort on that file you can't delete.
> 
> ==> We need to check we can remove the 'target', i.e. the URL(s) passed in
> del().
> But only the target, not the contained files.
> Of course, this applies to directories only. For files, we delete right away
> and
> get the error code of unlink anyway.
> 
> > But then the question arises how do we check we can remove it?
> I guess we could call rmdir(), and check the error code, even knowing it's
> not empty.
> ENOTEMPTY => we just have to delete what's inside first.
> EACCES => "Write access to the directory containing pathname was not allowed
> for the
>               process's effective uid, or one of the directories in
> pathname  did  not
>               allow search (execute) permission."
> Eh ! Doesn't this do the job for us ?
> Well, not over FTP of course.
> 
> Calling stat on the parent dir and checking the permissions would be a more
> general solution, but then it means checking user, group, other, suid bits,
> ...
> 
Another example: you call del on
file:/rootsfiles.tgz#tar:/tmp/mypornpic.jpg
You would have write access on the file, the /tmp dir in the tar, but
not on
the file containing the tar ... 
Please note that this problem isn't new and there was never a solution
for this
within kio. But with the new listRecursive approach, we run into new
problems
we should try to fix while fixing other problems ;)

So basicly we shouldn't do listRecursive as it comes, but check for move
and
del if we can also remove it while listing. This is more than
ignore_read_errors,
this is dont_ignore_remove_errors.

Greetings, Stephan

-- 
As long as Linux remains a religion of freeware fanatics,
Microsoft have nothing to worry about.  
                       By Michael Surkan, PC Week Online