Skip .DS_Store files in check_mode_recursive
Hackorum builds and tests every patch posted to the lists, not only commitfest submissions. This is Hackorum's own CI rather than the PostgreSQL project's, and it is still under testing - please report anything that looks wrong.
You can run a PostgreSQL built from this patch straight from Docker, with no checkout and no build:
docker run --rm -p 5432:5432 ghcr.io/hackorum-dev/postgres-patch:t253225psql -h localhost -U postgresBuilt from patchset v4 (message #4), August 23, 2026 at 05:25 AM.
Every patchset is also pushed to a branch of our PostgreSQL fork, so you can check out the same tree CI built. Without a PostgreSQL checkout:
git clone --branch t253225_4 https://github.com/hackorum-dev/postgres.gitIn a checkout you already have, add the fork once:
git remote add hackorum https://github.com/hackorum-dev/postgres.gitthen, for this patchset and every later one:
git fetch hackorum t253225_4 && git checkout t253225_4Patchset v4 (message #4) is on t253225_4
Hi,
I am repeatedly encountering an annoying failing test during 'make check-world'
execution on the macOS platform: pg_resetwal with the result:
Failed test 'check PGDATA permissions'
It happens because a filesystem object .DS_Store exists in the directory.
AFAIK, MacOS manages it on its own. Given that I almost never touch this module,
it seems the OS handles it automatically.
A quick dive into the mailing list history shows that this problem has been
discovered [1]pg_basebackup: errors on macOS on directories with ".DS_Store" files /messages/by-id/E258CE50-AB0E-455D-8AAD-BB4FE8F882FB@gmail.com and partly fixed [2]Commit d3fdfdcd1c7 'Skip .DS_Store files in server side utils' before.
It looks like this approach might be extended to TAP tests too. In the
attachment, see the sketch of the code and a minor test to prove that it works.
[1]: pg_basebackup: errors on macOS on directories with ".DS_Store" files /messages/by-id/E258CE50-AB0E-455D-8AAD-BB4FE8F882FB@gmail.com
/messages/by-id/E258CE50-AB0E-455D-8AAD-BB4FE8F882FB@gmail.com
[2]: Commit d3fdfdcd1c7 'Skip .DS_Store files in server side utils'
--
regards, Andrei Lepikhov,
pgEdge
Attachments:
v0-0001-Skip-.DS_Store-files-in-check_mode_recursive.patchtext/plain; charset=UTF-8; name=v0-0001-Skip-.DS_Store-files-in-check_mode_recursive.patchDownload+19-2
On 2026-07-28 Tu 4:53 AM, Andrei Lepikhov wrote:
Hi,
I am repeatedly encountering an annoying failing test during 'make check-world'
execution on the macOS platform: pg_resetwal with the result:Failed test 'check PGDATA permissions'
It happens because a filesystem object .DS_Store exists in the directory.
AFAIK, MacOS manages it on its own. Given that I almost never touch this module,
it seems the OS handles it automatically.A quick dive into the mailing list history shows that this problem has been
discovered [1] and partly fixed [2] before.It looks like this approach might be extended to TAP tests too. In the
attachment, see the sketch of the code and a minor test to prove that it works.[1] pg_basebackup: errors on macOS on directories with ".DS_Store" files
/messages/by-id/E258CE50-AB0E-455D-8AAD-BB4FE8F882FB@gmail.com
[2] Commit d3fdfdcd1c7 'Skip .DS_Store files in server side utils'
Minor perl nit:
I don't think you need to say
return if basename($File::Find::name) eq '.DS_Store';
you can just say
return if $_ eq '.DS_Store';
cheers
andrew
--
Andrew Dunstan
EDB: https://www.enterprisedb.com
On 28 Jul 2026, at 13:56, Andrew Dunstan <andrew@dunslane.net> wrote:
On 2026-07-28 Tu 4:53 AM, Andrei Lepikhov wrote:
I am repeatedly encountering an annoying failing test during 'make check-world'
execution on the macOS platform: pg_resetwal with the result:Failed test 'check PGDATA permissions'
It happens because a filesystem object .DS_Store exists in the directory.
AFAIK, MacOS manages it on its own. Given that I almost never touch this module,
it seems the OS handles it automatically.A quick dive into the mailing list history shows that this problem has been
discovered [1] and partly fixed [2] before.It looks like this approach might be extended to TAP tests too. In the
attachment, see the sketch of the code and a minor test to prove that it works.
Off the cuff, seems reasonable.
Minor perl nit:
I don't think you need to say
return if basename($File::Find::name) eq '.DS_Store';
you can just say
return if $_ eq '.DS_Store';
Since the rest of the function use $File::Find::name it does however seem a bit
clearer for those less well versed in Perl to use the proposed programming? I
had to go read File::Find and I assume I am not the only one =)
--
Daniel Gustafsson
On 28/07/2026 21:56, Andrew Dunstan wrote:
On 2026-07-28 Tu 4:53 AM, Andrei Lepikhov wrote:
I don't think you need to sayreturn if basename($File::Find::name) eq '.DS_Store';
you can just say
return if $_ eq '.DS_Store';
Thank you, done.
I implemented it this way for consistency and to be independent of the value of
the 'no_chdir' option.
--
regards, Andrei Lepikhov,
pgEdge