Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files - Mailing list pgsql-bugs

From Michael Paquier
Subject Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files
Date
Msg-id ZKioRpLcqW1oqWhO@paquier.xyz
Whole thread Raw
In response to Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files  (Daniel Gustafsson <daniel@yesql.se>)
Responses Re: pg_basebackup: errors on macOS on directories with ".DS_Store" files
List 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

Attachment

pgsql-bugs by date:

Previous
From: Laurenz Albe
Date:
Subject: Re: BUG #18017: configure --with-ldap fails when openldap is installed
Next
From: Michael Paquier
Date:
Subject: Re: BUG #18016: REINDEX TABLE failure