Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files
От | Michael Paquier |
---|---|
Тема | Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files |
Дата | |
Msg-id | ZKioRpLcqW1oqWhO@paquier.xyz обсуждение исходный текст |
Ответ на | Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files (Daniel Gustafsson <daniel@yesql.se>) |
Ответы |
Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files
|
Список | pgsql-bugs |
On Fri, Jul 07, 2023 at 09:23:38AM +0200, Daniel Gustafsson wrote: > On 7 Jul 2023, at 01:05, Tom Lane <tgl@sss.pgh.pa.us> wrote: >> On the whole, I think I'd vote for blocking .DS_Store only, even >> in HEAD. (IIRC, I thought differently to start with, but today >> I'm feeling conservative about it.) If there are other special >> file names on other platforms, we could add some more targeted >> exceptions; but dropping all hidden files seems more likely to >> break things than be helpful. > > I think the case for skipping all hidden files is that it would offer more > consistency with other serverside filesystem reads are performed. After > .DS_Store I would think that editor swapfiles would be other likely culprit of > hidden-but-not-belonging files. .DS_Store is not the only hidden file pattern that could be used by a filesystem for its metadata. And I don't quite see what we gain by only ignoring it, letting the others be. My take would be to just ignore all of them, and I'm OK even if it means to do so only on HEAD per the argument of being careful with stable branches. I cannot get excited about the potential use case where someone decides that it would be a good idea to include a hidden file, as well. It's not like it offers any kind of additional protection. Actually, it can make the debugging of a configuration a worse experience. -- Michael
Вложения
В списке pgsql-bugs по дате отправления: