> Thanks, I think I see the problem now. Please try the attached patch; I
> haven't tested myself as I lack access to macOS. Thanks.
> <0001-renameatu-port-to-macOS-tmpfs.patch>
It looks like this patch solves the problem.
> Thanks, but as I don't have access to a macOS machine I don't know what "the
> issue" is. What are the symptoms visible to the user? Can you do the
> equivalent of an strace to show us what system calls are being executed?
>
> As near as I can make out, on macOS mv should be doing the
> Can you give a way to reproduce the probglem on a macOS system, assuming one
> has a tmpfs filesystem /A and a non-tmpfs filesystem /B? The scenario wasn't
> entirely clear from the bug report.
Running the command “mount_tmpfs ~/mntpnt” mounts a tmpfs (and non CoW)
filesystem at ~/mntpnt.
> macOS is different in that /tmp isn’t actually on a tmpfs filesystem, but is
> rather just a normal directory on the main data volume that is cleaned on
> boot. One has to manually mount a tmpfs volume themselves with mount_tmpfs.
> Anyways, I’ll try the tarball linked and see if the issue
> I don't observe this problem with the latest development version of
> coreutils. Here's how I tried to reproduce the problem on macOS 11.3.1 20E241:
>
> % touch /tmp/
> % src/mv /tmp/ /tmp/
>
> and it worked OK.
macOS is different in that /tmp isn’t actually on a tmpfs
Hello,
It appears that in coreutils 9.0 and greater, the mv command is broken on
non-APFS filesystems on macOS. For example, on Apple tmpfs, it fails whenever
moving a file with ENOTSUPP. It works fine on APFS filesystems (which is the
primary macOS filesystem), however, so I assume it slipped
> So, not only does macOS lseek disagree with all other implementations, it
> even disagrees with the Darwin documentation.
Oh wow, that’s convoluted.
> To work around this macOS problem I installed the attached further patch into
> Gnulib and propagated it into coreutils. Please try the
Sure, here’s the dtruss output:
SYSCALL(args)= return
access("/AppleInternal/XBS/.isChrooted\0", 0x0, 0x0) = -1 Err#2
bsdthread_register(0x1AEC802C8, 0x1AEC802BC, 0x4000) = 1073742303 0
shm_open(0x1AEB48F55, 0x0, 0xDD8000) = 3 0
fstat64(0x3,
It doesn’t seem like this patch works. I compiled from the tarball you
provided, but the destination file is still filled with NULL chars.
> On Nov 15, 2021, at 5:46 PM, Sudhip Nashi via GNU coreutils Bug Reports
> wrote:
>
> Awesome, thanks for the quick response! I’ll give this
Awesome, thanks for the quick response! I’ll give this a go and let you know
the results.
> On Nov 15, 2021, at 5:41 PM, Paul Eggert wrote:
>
> On 11/15/21 10:37, Sudhip Nashi wrote:
>> Turns out lseek is broken (or at least works differently) on macOS as well
>>
> On Nov 15, 2021, at 11:33, Paul Eggert wrote:
>
> Is the source file on a ZFS file system by any chance? See my lseek comment
> below.
>
>> On 11/15/21 07:48, Cameron Katri via GNU coreutils Bug Reports wrote:
>>
>> stat64("/tmp/test\0", 0x16DDC36C0, 0x0) = 0 0
>>
Hello,
Cross-filesystem copying seems to have been broken in the latest coreutils
release on macOS. Running a command like ‘cp /usr/bin/clear /tmp/test’ appears
to return successfully, but if one analyzes /tmp/test, it’s filled with NULL
characters. However, copying works fine when the source
12 matches
Mail list logo
