[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: m4 didn't work with files in FAT system on Mac OS
From: |
光先邹 |
Subject: |
Re: m4 didn't work with files in FAT system on Mac OS |
Date: |
Thu, 1 May 2014 13:57:06 +0800 |
Hi Eric,
Following your suggestion, I tried to use fstatvfs() to get
filesystem type, but i didn't find which field can be used to do that.
The OS system is Mac OS Mavericks, the project lied in a TrueCrypt
volume which was formatted as FAT filesystem.
% uname -a
Darwin zgx.local 13.1.0 Darwin Kernel Version 13.1.0: Thu Jan 16
19:40:37 PST 2014; root:xnu-2422.90.20~2/RELEASE_X86_64 x86_64
% mount | grep msdos
/dev/disk1 on /Users/zouguangxian/Volumes/Windows7X (msdos, local,
nodev, nosuid, noowners, mounted by zouguangxian)
% automake --version
automake (GNU automake) 1.14.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later
<http://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Tom Tromey <address@hidden>
and Alexandre Duret-Lutz <address@hidden>.
% autoconf --version
autoconf (GNU Autoconf) 2.69
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<http://gnu.org/licenses/gpl.html>, <http://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
the patch is:
% diff -u m4-1.4.17.orig/src/debug.c m4-1.4.17/src/debug.c
--- m4-1.4.17.orig/src/debug.c 2013-09-22 13:50:43.000000000 +0800
+++ m4-1.4.17/src/debug.c 2014-05-01 13:44:24.000000000 +0800
@@ -23,6 +23,8 @@
#include <stdarg.h>
#include <sys/stat.h>
+#include <sys/param.h>
+#include <sys/mount.h>
/* File for debugging output. */
FILE *debug = NULL;
@@ -151,6 +153,20 @@
&& stdout_stat.st_dev == debug_stat.st_dev
&& stdout_stat.st_ino != 0)
{
+ /* on fat file systems, zero-length files share this magic value */
+ if (debug_stat.st_ino == 999999999)
+ {
+ struct statfs sfsb;
+ if (fstatfs (fileno (debug), &sfsb) == 0)
+ {
+ if (strcasecmp (sfsb.f_fstypename, "msdos") == 0
+ || strcasecmp (sfsb.f_fstypename, "exfat") == 0)
+ {
+ return;
+ }
+ }
+ }
+
if (debug != stderr && close_stream (debug) != 0)
{
M4ERROR ((warning_status, errno,
----
Zou Guangxian
2014-05-01 12:31 GMT+08:00 Eric Blake <address@hidden>:
> On 04/30/2014 10:10 PM, 光先邹 wrote:
>
>>
>> The reason is st_ino of empty file in FAT system is 999999999, which will
>> lead debug set back to stdout in function debug_set_file. Here is a patch
>> which will resolve this problem.
>
> Thanks for the report. However, I'd rather you get the filesystem bug
> fixed rather than trying to patch lots of individual programs that are
> all negatively impacted by the filesystem bug.
>
>>
>>
>> % diff -u m4-1.4.17.orig/src/debug.c m4-1.4.17/src/debug.c
>>
>> --- m4-1.4.17.orig/src/debug.c 2013-09-22 13:50:43.000000000 +0800
>>
>> +++ m4-1.4.17/src/debug.c 2014-05-01 11:55:41.000000000 +0800
>>
>> @@ -23,6 +23,8 @@
>>
>
> Your patch came through with whitespace munging; any chance you can
> convince your mailer to send it in a way that won't be corrupted in transit?
>
>>
>> #include <stdarg.h>
>>
>> #include <sys/stat.h>
>>
>> +#include <sys/param.h>
>>
>> +#include <sys/mount.h>
>>
>
> These files are not POSIX, and therefore cannot be expected to exist on
> all platforms. To use them, you'd first have to add configure.ac checks
> on whether they exist.
>
>
>>
>> + if(debug_stat.st_ino == 999999999)
>
> Style: space before (
>
>>
>> + {
>>
>> + struct statfs sfsb;
>>
>> + if(fstatfs(fileno (debug), &sfsb) == 0)
>
> and again
>
>>
>> + {
>>
>> + if (strcasecmp(sfsb.f_fstypename, "msdos") == 0
>
> and again.
>
> f_fstypename is not a portable member of struct statfs; more configure
> checks are required. In fact, fstatfs() is not portable; POSIX only
> requires fstatvfs(). I need more details about your setup - which
> kernel are you using, and which version of the fat filesystem?
>
> Again, this feels too hacky to include in m4 proper; the real bug is in
> the file system for violating POSIX semantics on returning an inode
> number that reliably determines a unique file.
>
> --
> Eric Blake eblake redhat com +1-919-301-3266
> Libvirt virtualization library http://libvirt.org
>