Ticket #197 (closed defect: invalid)
phing delete task sometimes fails to delete file that could be deleted
| Reported by: | phajdan.jr@… | Owned by: | hans |
|---|---|---|---|
| Priority: | minor | Milestone: | 2.3.1 |
| Component: | phing-tasks-system | Version: | 2.3.0 |
| Keywords: | Cc: |
Description
I have a directory with 777 chmod and inside I have files with 644 chmod, but owned by different user than me (common situation for web cache files etc. - this owner is then apache).
Simple unlink() would work for these files, but phing calls is_writable first (it returns false), and fails to delete the file.
I propose the following solution: when trying to delete file, instead of checking if it's writable etc. - just try to delete it, and check return value of unlink.
Attachments
Change History
comment:2 Changed 4 years ago by phajdan.jr@…
No, it didn't fix it. You see, there is this call to is_writable in canDelete, and that's the problem.
comment:3 Changed 4 years ago by hans
Yes, but in r258 the canDelete() method performs an is_writable() check on the parent directory. That check shouldn't be failing on the scenario you are describing (if your directory is chmod 777 then is_writable() should be true).
Moreover, this was implemented (per #155) since this is the way that perms are checked for unix operating systems.
comment:4 Changed 4 years ago by phajdan.jr@…
Anyway, I have phing 2.3.0 and it can't delete such file, while unlink can.
comment:5 Changed 4 years ago by hans
Ok -- I just want to make sure that I understand what the bug is. canDelete() needs to be fixed so that it works correctly. I appreciate that we could just call unlink() (and that may make sense ultimately), but I'd also like the FileSystem API to work as expected :)
Can you paste an ls -l on the dir and indicate the user you are running as, so that we can reproduce this exactly? Thanks!
comment:6 Changed 4 years ago by phajdan.jr@…
That's weird, but now I can't reproduce this behavior. I checked in logs that I was using phing 2.3.0 etc, and I was sure I had this problem because I re-implemented delete task using unlink.
But now it works, so I don't know...
I will paste relevant output anyway:
drwxrwxrwx 5 user users 24576 Dec 11 16:34 cache/
-rw-r--r-- 1 apache apache 8752 Dec 11 16:39 classmap
Can you have a look at #155. I thought that issue fixed this problem. That should have been fixed for 2.3.0, though. (I assume you are using 2.3.0 as ticket version indicates?)