On Sun, May 14, 2023 at 8:32 PM Albretch Mueller <lbrt...@gmail.com> wrote: > > I have been mounting an NTFS file system on a Windows laptop without > any problems whatsoever with a Debian Live DVD: > > $ uname -a > Linux debian 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) > x86_64 GNU/Linux > > and even though Linux utilities are telling me I do have space on the drive: > > $ date; sudo df -h | grep "Filesystem\|/dev/sd" > Sun 14 May 2023 06:55:23 PM UTC > Filesystem Size Used Avail Use% Mounted on > /dev/sda1 286G 167G 120G 59% /media/user/60320G593EB7250F > $ > > $ date; time sudo du --summarize --human-readable > /media/user/60320G593EB7250F > Sun 14 May 2023 07:13:43 PM UTC > 166G /media/user/60320G593EB7250F > > real 0m45.230s > user 0m1.073s > sys 0m15.443s > $ > > when I try to save or download a file I consistently get the same error > message: > > $ cp "No space left on device" > No_space_left_on_device.txt > bash: No_space_left_on_device.txt: No space left on device > > that started happening right after a WiFi connection at a library was > shutdown, which I waited for with my script running, accessing the > Internet, because I wanted to test such a case. Script "gracefully" > worked as programmed to do, but that other error started right after > the connection was cut off. > > I have no idea how could those two things be related! Why would that > happen? Any suggestions, please?
I don't know if it's related... I seem to recall the GNUlib folks talking about a cp bug on sparse files. It looks like it may be fixed in coreutils release 9.2 (2023-03-20): https://github.com/coreutils/coreutils/blob/master/NEWS#L233 If I recall correctly, it had something to do with the way copy_file_range worked. (Or maybe, it did not work as expected). Jeff
