Bug#1008507:
Hi, On 2022-03-29 17:53, Joshua Hudson wrote: > diff -ur glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c > glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c > --- glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29 > 17:50:12.558027042 -0700 > +++ glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29 > 17:52:33.262157543 -0700 > @@ -183,6 +183,11 @@ > case XFS_SUPER_MAGIC: >return XFS_LINK_MAX; > > +case MSDOS_SUPER_MAGIC: > +#ifdef EXFAT_SUPER_MAGIC // For when it gets added in about 30 years > +case EXFAT_SUPER_MAGIC: > +#endif > + return 1; > case LUSTRE_SUPER_MAGIC: >return LUSTRE_LINK_MAX; If you ended with a patch, the best is probably to submit it upstream to libc-al...@sourceware.org . Regards Aurelien -- Aurelien Jarno GPG: 4096R/1DDD8C9B aurel...@aurel32.net http://www.aurel32.net
Bug#1008507:
diff -ur glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c --- glibc.orig/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29 17:50:12.558027042 -0700 +++ glibc/glibc/sysdeps/unix/sysv/linux/pathconf.c2022-03-29 17:52:33.262157543 -0700 @@ -183,6 +183,11 @@ case XFS_SUPER_MAGIC: return XFS_LINK_MAX; +case MSDOS_SUPER_MAGIC: +#ifdef EXFAT_SUPER_MAGIC // For when it gets added in about 30 years +case EXFAT_SUPER_MAGIC: +#endif + return 1; case LUSTRE_SUPER_MAGIC: return LUSTRE_LINK_MAX;
Bug#1008507:
/* reproduce glibc bug */
/*
* I don't typically care what the return of pathconf(..., _PC_LINK_MAX)
* is; I just care whether or not it's greater than 1 because I'm checking
* whether the filesystem supports hard links or not.
*/
#include
#include
#include
#include
#include
#include
int main()
{
char file[40];
char dir[40];
char commandbuf[120];
sprintf(file, "/tmp/%u.img", getpid());
sprintf(dir, "/tmp/%u.mnt", getpid());
FILE *fimage = fopen(file, "wb");
fseek(fimage, 1440 * 1024 - 1, SEEK_SET);
fputc(0, fimage);
fclose(fimage);
mkdir(dir, 0);
sprintf(commandbuf, "mkfs.fat /tmp/%u.img", getpid());
if (system(commandbuf) != 0) {
rmdir(dir);
unlink(file);
return 1;
}
sprintf(commandbuf, "mount -o loop -t msdos %s %s", file, dir);
if (system(commandbuf) != 0) {
rmdir(dir);
unlink(file);
return 1;
}
int r;
printf("Testing pathconf(%s, _PC_LINK_MAX)...");
r = pathconf(dir, _PC_LINK_MAX) != 1;
printf(r ? "Failed\n" : "OK\n");
sprintf(commandbuf, "umount %s", dir);
system(commandbuf);
rmdir(dir);
unlink(file);
return r;
}
Bug#1008507: libc6: pathconf("mountpont of FAT filesystem", _PC_LINK_MAX) returns 127, expected 1
Package: libc6 Version: All of them Severity: normal Tags: newcomer Dear Maintainer, what lead up to the situation is well-described in my stackoverflow post: https://stackoverflow.com/questions/71641957/how-to-check-if-a-filesystem-supports-hard-links-in-linux Since posting it, I have traced the bug through the glibc sources and found that it's bugged. There's cases for common filesystems that have nonstandard values, but you almost never care what the actual value is. On the other hand, there are no cases for writable filesystems that simply don't have hard links. (FAT). EXFAT would also fall into this but that only exists as a FUSE module right now. These turn out to be the ones we care about becasue they are three of the four widely supported filesystems on removable media (with the fourth being UDF). Writing a patch is trivial. Getting it into glibc, well I'm gonna try but you may have more luck. -- System Information: Debian Release: 10.11 APT prefers oldstable-updates APT policy: (500, 'oldstable-updates'), (500, 'oldstable') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.19.0-18-amd64 (SMP w/4 CPU cores) Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1), LANGUAGE=en_US (charmap=ISO-8859-1) Shell: /bin/sh linked to /bin/dash Init: sysvinit-sysv LSM: AppArmor: enabled
