From: Rich Felker <dalias@libc.org>
To: Stephen Von Takach <steve@place.technology>
Cc: musl@lists.openwall.com, Viv Briffa <viv@place.technology>
Subject: Re: unlink on NFS volume fails silently
Date: Mon, 7 Jul 2025 21:08:12 -0400 [thread overview]
Message-ID: <20250708010811.GL1827@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAASffotpA8p06wsnAz7xHAuhhM2t0bAphkmNSpc9qV7yafh+zQ@mail.gmail.com>
On Sun, Jul 06, 2025 at 04:25:31PM +1000, Stephen Von Takach wrote:
> Hi,
>
> We recently had to move a service from being built on alpine linux to
> debian linux as we were getting silent failures when deleting a directory
> with many files on an NFS volume. Basically this call to unlink was not
> raising an error if the file failed to delete
> https://github.com/crystal-lang/crystal/blob/master/src/crystal/system/unix/file.cr#L129
>
> We replicated the issue in an alpine container with rm -rf
> /nfs_mount/git_repo_to_delete and it also failed to successfully delete all
> the files, it did raise an error though (I assume it checked the file was
> removed before continuing) not entirely sure.
>
> Both these operations succeed with glibc when using debian.
> Looks a bit like this issue:
> https://gitlab.alpinelinux.org/alpine/aports/-/issues/10960
Assuming you actually traced and saw the unlink syscall succeed, the
root cause here is the filesystem/kernel lying about that. Standard
"NFS Considered Harmful" stuff.
But the fact that you're seeing different behavior on Alpine is almost
surely a matter of busybox rm vs GNU coreutils differences in how they
behave under faulty kernel behavior. The easy solution is probably
installing the coreutils package. Otherwise, investigate what busybox
is doing differently and if there's a way it could be made more
reliable in this situation.
Rich
next prev parent reply other threads:[~2025-07-08 1:08 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-07-06 6:25 [musl] unlink on NFS volume fails silently Stephen Von Takach
2025-07-07 18:26 ` Markus Wichmann
2025-07-08 1:08 ` Rich Felker [this message]
2025-07-09 3:59 ` [musl] " Stephen Von Takach
2025-07-09 18:41 ` Rich Felker
2025-07-09 23:01 ` [musl] " Stephen Von Takach
2025-07-10 0:03 ` Rich Felker
2025-07-10 4:58 ` Stephen Von Takach
2025-07-10 15:44 ` Rich Felker
2025-07-10 17:01 ` Nathan McSween
2025-07-10 17:11 ` Rich Felker
2025-07-10 21:25 ` Stephen Von Takach
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250708010811.GL1827@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=musl@lists.openwall.com \
--cc=steve@place.technology \
--cc=viv@place.technology \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).