Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files
От | Daniel Gustafsson |
---|---|
Тема | Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files |
Дата | |
Msg-id | 24B9C983-910D-466A-8E1E-E5865B1B4E27@yesql.se обсуждение исходный текст |
Ответ на | Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files (Michael Paquier <michael@paquier.xyz>) |
Ответы |
Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files
|
Список | pgsql-bugs |
> On 8 Jul 2023, at 02:05, Michael Paquier <michael@paquier.xyz> wrote: > > 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. Judging by the thread there seems to be concensus on skipping .DS_Store files in all branches, with a few +1's for skipping all hidden files in HEAD. I'll prepare a patch for the former and we can pick up the discussion on the latter ones that's done. -- Daniel Gustafsson
В списке pgsql-bugs по дате отправления: