Re: backup manifests and contemporaneous buildfarm failures
| От | Robert Haas |
|---|---|
| Тема | Re: backup manifests and contemporaneous buildfarm failures |
| Дата | |
| Msg-id | CA+TgmobNQVsFvE=qFSJqu=A-wFnaq23SAQkvV3sx3Cu1Ho==Pg@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: backup manifests and contemporaneous buildfarm failures (Tom Lane <tgl@sss.pgh.pa.us>) |
| Ответы |
Re: backup manifests and contemporaneous buildfarm failures
|
| Список | pgsql-hackers |
On Fri, Apr 3, 2020 at 8:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Yeah, so it would seem. The buildfarm script uses rmtree to clean out > the old build tree. The man page for File::Path suggests (but can't > quite bring itself to say in so many words) that by default, rmtree > will adjust the permissions on target directories to allow the deletion > to succeed. But that's very clearly not happening on some platforms. > (Maybe that represents a local patch on the part of some packagers > who thought it was too unsafe?) Interestingly, on my machine, rmtree coped with a mode 0 directory just fine, but mode 0400 was more than its tiny brain could handle, so the originally committed fix had code to revert 0400 back to 0700, but I didn't add similar code to revert from 0 back to 0700 because that was working fine. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: