On 6/25/25 3:44 AM, Richard Weinberger wrote:
Bash Version: 5.2
Patch Level: 37
Release Status: release
Description:
getcwd() as implemented in lib/sh/getcwd.c can return with NULL and a
stale errno value if the algorithm fails. It aborts if readdir()
returns NULL and
On Thursday, June 26, 2025, Martin D Kealey wrote:
> There's a fairly obvious race condition where another process replaces a
> directory entry
That's not the case here.
between readlink and lstat.
Who said anything about them?
> I would like bash to cope more gracefully with "unexpected"
On Thu, 26 Jun 2025 at 04:07, Oğuz wrote:
> On Wednesday, June 25, 2025, Richard Weinberger
> wrote:
> >
> > This can happen on filesystems where d_ino != st_ino
>
> i.e. a broken filesystem.
Or not broken.
There's a fairly obvious race condition where another process replaces a
direc
On Donnerstag, 26. Juni 2025 08:45 Phi Debian wrote:
> That's true that the bash shell-init: could be omitted and defered until
> one ask for pwd explicitly.
>
> I don't see any *ino* jazz here, but the classic, my current dir has been
> removed under my feet.
>
> I may have mis-read the *ino* pa
In the given reproducer, I am not sure btrfs is relevant here on my good'ol
ext4 I got.
$ mount | grep '/d2 ' | sed 's/(.*//'
/dev/sda1 on /d2 type ext4
$ cd /d2 ; mkdir -p a/b/c ; cd a/b/c ; rmdir /d2/a/b/c
$ bash -c 'pwd'
shell-init: error retrieving current directory: getcwd: cannot access
pa
On Mittwoch, 25. Juni 2025 21:28 Oğuz wrote:
> On Wednesday, June 25, 2025, Richard Weinberger
> wrote:
> >
> > I'm not asking you to implement a workaround
>
>
> I'm just another user. I agree that a descriptive error message is better
> than a random one. But if your system can't return the sa
On Wednesday, June 25, 2025, Richard Weinberger
wrote:
>
> I'm not asking you to implement a workaround
I'm just another user. I agree that a descriptive error message is better
than a random one. But if your system can't return the same inode number
for the same file from two standard functions
On Wednesday, June 25, 2025, Richard Weinberger
wrote:
>
> This can happen on filesystems where d_ino != st_ino
i.e. a broken filesystem. What does any of this have to do with bash?
--
Oğuz
On Wednesday, June 25, 2025, Richard Weinberger
wrote:
>
> Having different results for d_ino and st_ino is not that uncommon.
>
POSIX defines both fields to contain the unique serial number of a file in
a filesystem. I don't think Bash is at fault here for not assuming
otherwise.
--
Oğuz
Hello Oğuz,
On Mittwoch, 25. Juni 2025 20:07 Oğuz wrote:
> On Wednesday, June 25, 2025, Richard Weinberger
> wrote:
> >
> > This can happen on filesystems where d_ino != st_ino
>
>
> i.e. a broken filesystem. What does any of this have to do with bash?
Bash could, for example, check th
10 matches
Mail list logo
