From MAILER-DAEMON Wed Feb 16 11:11:34 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nKMty-0002SC-KI for mharc-info-mtools@gnu.org; Wed, 16 Feb 2022 11:11:34 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55504) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKMtx-0002PP-DA for info-mtools@gnu.org; Wed, 16 Feb 2022 11:11:33 -0500 Received: from mx0b-002c1b01.pphosted.com ([148.163.155.12]:41666) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKMtu-0007Fh-2j for info-mtools@gnu.org; Wed, 16 Feb 2022 11:11:32 -0500 Received: from pps.filterd (m0127841.ppops.net [127.0.0.1]) by mx0b-002c1b01.pphosted.com (8.16.1.2/8.16.1.2) with ESMTP id 21G8q602001486 for ; Wed, 16 Feb 2022 08:11:22 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nutanix.com; h=content-type : message-id : date : from : to : subject : mime-version; s=proofpoint20171006; bh=hjo7OtsIJlEtwzv5XdqaB9YjKJ7EW424wZwQPfa0bog=; b=SjX9JNIIOZNFPLZtdBMwATCao91DusnL2mVQDDokJ4yxBvJunsM0vDXV9922t7bDtTV+ 1KW1Qd+Hk88gxY9ECxmk9Ko9vJ0ckIPvKq4w73s5Tb1yEHc5Zm5YjgDm36iEj0/JRII/ 5EndfeThVml7vMryjUopgkG+33AHMcqGJ0hbPFpoL1RySZ8VXSNMqDyRHr7R187f0A7x 14BWw3MkBHmGk7+LKfI5Me2+Muv14jH872CkjcYDols1KqMmQGfHy7SU6LDi8kwjZfHx wxLk+/4YXNpRPOn7ch2f9LjkQybMclapndAGNl2qlMk2DwzMOvHrI5VnRm2gXxXyDp2m lQ== Received: from nam12-mw2-obe.outbound.protection.outlook.com (mail-mw2nam12lp2048.outbound.protection.outlook.com [104.47.66.48]) by mx0b-002c1b01.pphosted.com (PPS) with ESMTPS id 3e8n431s22-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for ; Wed, 16 Feb 2022 08:11:22 -0800 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fi1hfgXBXNjd/bwAgRFYP7phFnJPQ189++DvscO9vKW+Mj7qebVhgzGq7SSldbCwDOaJBjKcWTv7G5H2oqRawUMV9rPnVGAJ72NYHxVXVeleCC7kdYy1bzBv85J5RjVlQF0FrE5THxagagTSVcdO2B2FfSh7KOo8MD9hO5nNNXnMmipC8jpH3TH6wOYHV0251uR4H9r37QeK9PgELASLescgbU7Lf9P99oXEXKq5c/wq4W4UycHUvnwrpMZTukyuDX4dnVLBr71vVm69EX6uwhkt9qcmc3fC0F8/3S0AdirwInwPW7GaB9udfzUfXBfaxn2/s+mdydZMWgOtYqQLxA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=hjo7OtsIJlEtwzv5XdqaB9YjKJ7EW424wZwQPfa0bog=; b=HOdmwCOeBmc9gpNzOdb0cQtN48nD8bMzDubBV+9LTJBozNoBnm1TgII8JRBSJTtBQeZVmba1Sep+xN1/mI+2pcj2V8MxxurjW8V0Xw2oBCUwCUKecYPNk9ycSYXWaehSIP78m8yBv2xEtIBsB/LnXrC1ni1coXFLGT2K1cIFPvgwVIZj8JJT8dcQ+GTDh9VKXDosUK3eWWgvQkkAPU6PTa+OR1mBgbnWR3fcufiBdCeiX/6Fr1pNMy10JyouDsBcr9WqxFoo9vwPv4TbrigH6YnI4VuaLez1jTYAjX2tY1bINTZ8Il1E7EwQOfnsqVxGBjE1oGKa7ZfmikgcXB0uEQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from CH0PR02MB7964.namprd02.prod.outlook.com (2603:10b6:610:105::16) by SJ0PR02MB7296.namprd02.prod.outlook.com (2603:10b6:a03:29b::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4975.11; Wed, 16 Feb 2022 16:11:20 +0000 Received: from CH0PR02MB7964.namprd02.prod.outlook.com ([fe80::ec35:5c4f:440d:8350]) by CH0PR02MB7964.namprd02.prod.outlook.com ([fe80::ec35:5c4f:440d:8350%3]) with mapi id 15.20.4995.016; Wed, 16 Feb 2022 16:11:19 +0000 Content-Type: multipart/mixed; boundary="------------eNfc57mG7noddJ3095LnkyAZ" Message-ID: <11dc9e45-596a-413c-9695-8d9bb5281d58@nutanix.com> Date: Wed, 16 Feb 2022 16:11:11 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Content-Language: en-US From: Jonathan Davies To: info-mtools@gnu.org X-ClientProxiedBy: AM9P192CA0025.EURP192.PROD.OUTLOOK.COM (2603:10a6:20b:21d::30) To CH0PR02MB7964.namprd02.prod.outlook.com (2603:10b6:610:105::16) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: bfe57f01-7229-4160-d981-08d9f166f7ef X-MS-TrafficTypeDiagnostic: SJ0PR02MB7296:EE_ X-Microsoft-Antispam-PRVS: x-proofpoint-crosstenant: true X-MS-Oob-TLC-OOBClassifiers: OLM:2887; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 7ixiHpOES1n87gOPG1QMXFqgEBx7MUPj7q4WTr752pcdNVr+odTwKKMoRLTdRo3fX5E8gcnTNr6epkHF+LY21Mksfa+jPCtM+lRC61xxG1ONIt1gZt1jNOIRQnbUfhlA5shDmtCIOTP0uXMaScLwRJgBwjdrBm3295K14Z569Q73PnS2vc8ac+8weUkBOvf3eGjfA3Lks++S4neCc4PZBgYsmJ+X1b7frdc9QUWX6kO1onbYZJZxwl8xY/NLJtfx8Ct8W0Rcddt6hoIxFY621tw6csAMTy0SGxe6I2PYHj7CWyS9e61t3rxJROcfVFNjleWJK5CeuZb3FI2Vcip/ptvxIeseF2i4mUO5siDXU2Vj8NPWpRLTSR7wbIhEArgpNLsrMu6UfJujVucV1eGffiQlZsKz4a6qDZDzI3XQn4eikEa72lNQYosj5QxXbuSa+s2LrQgnJPjP3saKNnSL27FHVYm5HIy85aIiDxRC/chcaaMPpF5yxJ9OqQaPou/93TFtMvKr8uYOlT31dftx0tK/xTQWsljCXA93wSVDmmLYaVTN6M9H1lFpGGRGdj6nJi/UChoLk54KyaHHOCT06uTswqpzA7NdxUKaU7oJ81i5QpiS0+nk1k3cHznDAgkKcHpT350iZif/CJONR9RvWoatB/2Q0VxcsMKV4FdwlH2aYX1spf9+VDkFePwoVfiqM4ofX2wnFO7cyzZ+gY7LExaKydDvFwmN5bURm6+PCQmkpJAn5NRTLkqhf3dSuvjUiSXXTbFbmrJxv37l78NIYA== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH0PR02MB7964.namprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230001)(366004)(186003)(44832011)(2906002)(2616005)(38100700002)(38350700002)(8676002)(36756003)(26005)(83380400001)(6506007)(52116002)(33964004)(8936002)(66476007)(66946007)(66556008)(6666004)(508600001)(6486002)(6512007)(6916009)(31696002)(316002)(235185007)(5660300002)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1102; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZmlpbGlqU05QVS80TmJ1bFhCZVIybFVFbjZtZkMxYk4wUUorTm9mT1VyRmxs?= =?utf-8?B?akNrS0g3Qy85dUU1VjRhMEhnbXp6c2FITGhlL0ZoS01xQW9RUE16dnZRamUv?= =?utf-8?B?K0cwL2NaZkFUWW02azNWOHhPVzlHWEZFWXMrVi91Y3FaVmp5ZkExYVN2dWht?= =?utf-8?B?bmREYTdVaWNSUit4VEtRcFAxd25VVjN0QlNTWVBTUnZFSkVZV2syNFlzVURt?= =?utf-8?B?ckUxNnNrbjNZUUlTNkwxQ1JlTW5HZUVTK2RXYUg1UjJYZjdMK3NMWlZsTitP?= =?utf-8?B?ZDZ3dmtQbUQwYVJjWEJpSEFKdkoyVWNiZ2owdi9YODlFSWYxakFST3BUUXVa?= =?utf-8?B?WmxLWHFBQlVTMTc0a0tFbk5pMEgxdllqWjF5Q014TG5KYlVaQk9zRENMTVdU?= =?utf-8?B?ZEIzMXBBK2JZT0ozSWMwUC9LSGIwS0JiaHlWbEhBK1dlcFFheGFIdEd6YjA1?= =?utf-8?B?V0tTcEdSZC9CcTJqS0wwN09TeUJpNDl6ZlpHRVpEMlI3c0dIUk8zcGtTdXJU?= =?utf-8?B?enE4c3FFcTVIVmVOQ2NKaUNPL3BsbE56REFXcG96N0FJQ0xUNmJtT2lmVXRW?= =?utf-8?B?aW1uam9oTTFyMHpKM3hPVjBuNTU0WlJ4SnpsOXlINmQ0ZFhPcWU4STI5WFJL?= =?utf-8?B?cFZGd3BGQ2l1TFhSM0VTMklJVjBER3RQSjlFaWJ6dUNGZlY0eVU5SHZ6cWd2?= =?utf-8?B?ajJ0d0NXNVcrNXVOeVd3N241SFFrdFZlUkwxTkVRL25RU2hrbDlGT0szaXo4?= =?utf-8?B?RWxOK0FHYzArK3g5K1hsZkdjRGZSUTNPK2xxNFNDLzNmMDVTWFVUZUlPdytB?= =?utf-8?B?U2hFYkJ1ditONUJyMkZ6ZzZoajg4b0N3K2d5eWxEaDV5a0tNbkdCcGY0U0FJ?= =?utf-8?B?TlV5WkRvQVozbU02aXkydHRpOGYvWk5rSUVxL3hHdWVLUW1nRklQNTNLbnZn?= =?utf-8?B?czJkUC9HN20zVjdtUXVPeUVCVlUrVUk2TkZxb29GUGVEMGdNck9IcE5NSVBT?= =?utf-8?B?SjlxbHBoY0lUQnJRSXdsVUswWjdNcG5YcWlicWFFMndKM0xCRTNJc1hITm5w?= =?utf-8?B?VERWVVBTSjl2eXdNNmFmQU83c3pLWk5ROTJqU0JYZ0hyTTMxMm0xRFM2eU1I?= =?utf-8?B?QldxNjYyMjAvYUpsVjhiNnUxQnYreTYwU3haTkRJbFNJbldCZjl1Nys4UzMv?= =?utf-8?B?R3NwdjhtWXNMbDB5MUxydXRpYnhURW8raUdDYkpjSjdPQjlTd0x4eDRHS0ts?= =?utf-8?B?cCtqQzI2MTh5TVI5eFBTcDY5Z1RuSVpGL0R0ZzBuODQxYUs3WXczd3phdGM0?= =?utf-8?B?QjU4VUpqMXhLazQ2R29TSnRpVXQ2MWF0Q3JiSWlvV1pMb3hiZ2RMZU1HUTJ2?= =?utf-8?B?YU1WVlpGNEVvOFlhNGgwRE9JMVpDNU5IdWhRVjg3cUU2bWliVmk3LzJIL3pD?= =?utf-8?B?VW9ad20vWG5uZnp4YTBleGpvWndqWW9YcVpyK3BNUyt5SlF1MjVLOVVCOEpt?= =?utf-8?B?dkxIZEllMnZRcTI1dWZSN045dG5qV091Nnp4Rk85S0tzVmp5NGYvWWV1M3Q0?= =?utf-8?B?RHpXMWovUE1JOWRaMFNqWElycG1kUGF4T0F2b1kySVRVcytCN0tWanVBV3gz?= =?utf-8?B?OEN1QytlbVpiY2tzeTlnMDd5elEyYjRpWW1td2YwN2h0UnJTS2JqMzl2YkZQ?= =?utf-8?B?dmU2OURlaHZWTG1WL1JhU0QrQ0Q0V3NwUVBsczg5dWlZVGdHQlMzdTZjR3Ny?= =?utf-8?B?K2NTOENKV29rMDJFNjFhZ0ZObGdwU0NPZE5ZN3FHYlNlTmY0b05DQmlGUHRx?= =?utf-8?B?aE14V2I3K0ZCTmIwMUtEclhGRmw0bGRFSk1QWHlSSDFSVGczTE0wV1B3MXQ3?= =?utf-8?B?aGJRcU1NUnpOMEJBZ3VZWFQ2SEd5SVVYOXNzdHpLWWhjVHY4NUpuK1JKWXNa?= =?utf-8?B?dERsa3VZazE3WmllZXZra0hHU1RSTlA1TVMyS2JMaHErUnEzSmpmUXdZNCtC?= =?utf-8?B?R05tSElnb1F3d2xWTHAxdEZUSEV5ZlZ0ZzUvUG04cjBVUE1aSUhzeE03d3NN?= =?utf-8?B?VTRWWG0waUhxSzJqbzFaMWhZK2Zxc05CaFZFR0RVSmRSQ0VVNVVBZmhkcHdz?= =?utf-8?B?cWpVdCtoR1ptSGpoT2F0cGxCUWM2VnprWnd2UXBrZUY0SlRaNUFKQmlTYmFa?= =?utf-8?B?aDM5MDI2Y2ZOWHVPSVAxbnFERmdzSFZJb3RBZmZ1UDVMc3NxdnBOaUwwUUpo?= =?utf-8?Q?ZfVZ32StvJy9xopsQufKyGShmD4Oi7uK31o9YIrVyY=3D?= X-OriginatorOrg: nutanix.com X-MS-Exchange-CrossTenant-Network-Message-Id: bfe57f01-7229-4160-d981-08d9f166f7ef X-MS-Exchange-CrossTenant-AuthSource: CH0PR02MB7964.namprd02.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2022 16:11:19.9378 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: bb047546-786f-4de1-bd75-24e5b6f79043 X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: XKeK8SS2ZI4HRfQccSju6zgnrN9lHJWluyLutUsRxthRnPHKV8JoEDykJnr4eGP568IT5J02t3J5iO5MXuRJrA07B2RdzElM4YAVQi63ak0= X-MS-Exchange-Transport-CrossTenantHeadersStamped: SJ0PR02MB7296 X-Proofpoint-ORIG-GUID: xC5G-evoZ6ggQpPjy9eehHIef3iR4m92 X-Proofpoint-GUID: xC5G-evoZ6ggQpPjy9eehHIef3iR4m92 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-16_07,2022-02-16_01,2021-12-02_01 X-Proofpoint-Spam-Reason: safe Received-SPF: pass client-ip=148.163.155.12; envelope-from=jond@nutanix.com; helo=mx0b-002c1b01.pphosted.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.083, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: [Info-mtools] [PATCH] mmd: avoid uninitialised byte in . and .. directory entries X-BeenThere: info-mtools@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Feb 2022 16:11:33 -0000 --------------eNfc57mG7noddJ3095LnkyAZ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Hello, Please find attached a patch that fixes an uninitialised byte when mmd creates . and .. directory entries. This helps make filesystem images deterministic and silences a warning from valgrind. Here is a sample extract from valgrind output on "mmd -i img ::foo" showing the warning: ==151012== Syscall param write(buf) points to uninitialised byte(s) ==151012== at 0x513CA90: __write_nocancel (in /usr/lib64/libc-2.17.so) ==151012== by 0x419F0E: file_io (plain_io.c:100) ==151012== by 0x40AD7E: force_io (force_io.c:38) ==151012== by 0x40AD7E: force_write (force_io.c:55) ==151012== by 0x40358B: _buf_flush (buffer.c:69) ==151012== by 0x403BD4: buf_flush (buffer.c:309) ==151012== by 0x41B5E2: flush_stream (stream.c:29) ==151012== by 0x41B5F2: flush_stream (stream.c:31) ==151012== by 0x41B5F2: flush_stream (stream.c:31) ==151012== by 0x41B5F2: flush_stream (stream.c:31) ==151012== by 0x416A4C: makeit (mmd.c:94) ==151012== by 0x415C6F: write_slots (mk_direntry.c:494) ==151012== by 0x415C6F: _mwrite_one (mk_direntry.c:623) ==151012== by 0x415E55: mwrite_one (mk_direntry.c:655) ==151012== by 0x416BE3: createDir (mmd.c:133) ==151012== by 0x416C61: createDirCallback (mmd.c:145) ==151012== by 0x40C4C6: handle_leaf (mainloop.c:237) ==151012== by 0x40CCFC: recurs_dos_loop (mainloop.c:351) ==151012== by 0x40CDE5: common_dos_loop (mainloop.c:454) ==151012== by 0x40D23D: dos_loop (mainloop.c:467) ==151012== by 0x40D23D: main_loop (mainloop.c:565) ==151012== by 0x416D96: mmd (mmd.c:198) ==151012== by 0x40332F: main (mtools.c:184) ==151012== Address 0x542351c is 22,572 bytes inside a block of size 131,072 alloc'd ==151012== at 0x4C29F73: malloc (vg_replace_malloc.c:309) ==151012== by 0x403C6C: buf_init (buffer.c:364) ==151012== by 0x40BCF3: fs_init (init.c:377) ==151012== by 0x41B7D7: open_root_dir (streamcache.c:69) ==151012== by 0x40CDBF: common_dos_loop (mainloop.c:450) ==151012== by 0x40D23D: dos_loop (mainloop.c:467) ==151012== by 0x40D23D: main_loop (mainloop.c:565) ==151012== by 0x416D96: mmd (mmd.c:198) ==151012== by 0x40332F: main (mtools.c:184) Regards, Jonathan --------------eNfc57mG7noddJ3095LnkyAZ Content-Type: text/x-patch; charset=UTF-8; name="0001-mmd-avoid-uninitialised-byte-in-.-and-.-directory-en.patch" Content-Disposition: attachment; filename*0="0001-mmd-avoid-uninitialised-byte-in-.-and-.-directory-en.pa"; filename*1="tch" Content-Transfer-Encoding: base64 RnJvbSA1ZjUxZjhmMzViZWI2MjNjNjYzZTJmM2RhZWU2OTAyNTZlOWFlZGUwIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBKb25hdGhhbiBEYXZpZXMgPGpvbmF0aGFuLmRhdmllc0BudXRh bml4LmNvbT4KRGF0ZTogRnJpLCAxMSBGZWIgMjAyMiAyMDo1NToyOSArMDAwMApTdWJqZWN0OiBb UEFUQ0hdIG1tZDogYXZvaWQgdW5pbml0aWFsaXNlZCBieXRlIGluIC4gYW5kIC4uIGRpcmVjdG9y eSBlbnRyaWVzCgptbWQncyBtYWtlaXQgZnVuY3Rpb24gY2FsbHMgbWtfZW50cnlfZnJvbV9iYXNl IHRvIHBvcHVsYXRlIHRoZSBzdHJ1Y3QKZGlyZWN0b3J5IGZvciBib3RoIHRoZSAnLicgYW5kICcu LicgZW50cmllcyBpbiB0aGUgZGlyZWN0b3J5IGJlaW5nCmNyZWF0ZWQuCgpUaGUgc3ViRW50cnku ZGlyIHRoYXQgaXMgcGFzc2VkIGZyb20gbWFrZWl0IHRvIG1rX2VudHJ5X2Zyb21fYmFzZSBpcwp1 bmluaXRpYWxpc2VkLiBta19lbnRyeV9mcm9tX2Jhc2UgKHZpYSBta19lbnRyeSkgd3JpdGVzIHRv IGFsbCBtZW1iZXJzCm9mIHRoZSBzdHJ1Y3QgZGlyZWN0b3J5IGV4Y2VwdCBDYXNlLiBUaGlzIGxl YWRzIHRvIGdhcmJhZ2Ugb3V0cHV0IGluCnRoYXQgYnl0ZSAob2Zmc2V0IDB4Yykgb2YgYSBkaXJl Y3RvcnkgZW50cnkgd2hlbiBtYWtlaXQgaW52b2tlcyBGTFVTSCwKYW5kIHZhbGdyaW5kIGNvbXBs YWlucyAiU3lzY2FsbCBwYXJhbSB3cml0ZShidWYpIHBvaW50cyB0byB1bmluaXRpYWxpc2VkCmJ5 dGUocykiLgoKSW4gcHJhY3RpY2UsIHRoaXMgZG9lc24ndCBhZmZlY3QgY29ycmVjdG5lc3MgYmVj YXVzZSB0aGUgY2FzZSBpcwppcnJlbGV2YW50IGZvciBub24tYWxwaGFiZXRpYyBuYW1lcyAnLicg YW5kICcuLicuIEhvd2V2ZXIsIGl0IGRvZXMgbGVhZAp0byBub24tZGV0ZXJtaW5pc3RpYyBvdXRw dXQgd2hpY2ggaXMgdW5kZXNpcmFibGUgZnJvbSBhIHJlcHJvZHVjaWJpbGl0eQpwb2ludCBvZiB2 aWV3OyBzZWUgaHR0cHM6Ly9yZXByb2R1Y2libGUtYnVpbGRzLm9yZy4KCk9uZSBzb2x1dGlvbiB3 b3VsZCBiZSB0byBleHBsaWNpdGx5IGluaXRpYWxpc2UgdGhlIENhc2UgYnl0ZSwgYnV0IGl0CnNl ZW1zIHBydWRlbnQgdG8gbWVtc2V0IHRoZSB3aG9sZSBzdWJFbnRyeSwgc28gdGhhdCBhc3N1bXB0 aW9ucyBhYm91dAp0aGUgaW1wbGVtZW50YXRpb24gb2YgbWtfZW50cnkgYXJlIG5vdCBtYWRlLiBU aGlzIG1pcnJvcnMgd2hhdCBPcGVuUm9vdApkb2VzIGJlZm9yZSBpdHMgYW5hbG9nb3VzIGludm9j YXRpb24gb2YgbWtfZW50cnlfZnJvbV9iYXNlLgotLS0KIG1tZC5jIHwgMSArCiAxIGZpbGUgY2hh bmdlZCwgMSBpbnNlcnRpb24oKykKCmRpZmYgLS1naXQgYS9tbWQuYyBiL21tZC5jCmluZGV4IGJi OWMxZDcuLjA4Njk1ODUgMTAwNjQ0Ci0tLSBhL21tZC5jCisrKyBiL21tZC5jCkBAIC04MSw2ICs4 MSw3IEBAIHN0YXRpYyBpbnQgbWFrZWl0KGRvc19uYW1lX3QgKmRvc25hbWUsCiAKIAkvKiB0aGlz IGFsbG9jYXRlcyB0aGUgZmlyc3QgY2x1c3RlciBmb3Igb3VyIGRpcmVjdG9yeSAqLwogCisJbWVt c2V0KCZzdWJFbnRyeSwgMCwgc2l6ZW9mKGRpcmVudHJ5X3QpKTsKIAlpbml0aWFsaXplRGlyZW50 cnkoJnN1YkVudHJ5LCBUYXJnZXQpOwogCiAJc3ViRW50cnkuZW50cnkgPSAxOwotLSAKMi45LjMK Cg== --------------eNfc57mG7noddJ3095LnkyAZ-- From MAILER-DAEMON Thu Feb 17 13:54:21 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nKlv3-0002fV-Ev for mharc-info-mtools@gnu.org; Thu, 17 Feb 2022 13:54:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49416) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKlv2-0002fK-HV for info-mtools@gnu.org; Thu, 17 Feb 2022 13:54:20 -0500 Received: from mout.gmx.net ([212.227.17.20]:49093) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKlux-0000Vn-8E for info-mtools@gnu.org; Thu, 17 Feb 2022 13:54:20 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645124050; bh=T6hCnh2AJ2wvHCCwcqDnJw9GYLoYDYfYiVHxcWbFY60=; h=X-UI-Sender-Class:Date:From:To:Subject; b=eaSeNIUcsc+6I55xGQBsGDKAXIquGkWKrsVEnecFxkI9cGBKxDNdmqOOqPNA/EdjE 30Oh76ofBr1XBaOujR3LA0batkvIShOoKyLK1h/H+6FJbQaIiEnci5wXjKrdb881PL OBssV9+bNW+/B4fPyt7sI599VoUudQWxJv2g4ltQ= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from scdbackup.webframe.org ([84.179.236.146]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1N4hvb-1oIxmv2Q2J-011mss for ; Thu, 17 Feb 2022 19:54:10 +0100 Date: Thu, 17 Feb 2022 19:54:33 +0100 From: "Thomas Schmitt" To: info-mtools@gnu.org Content-Type: text/plain; charset="utf-8" Message-Id: <9613380351189766901@scdbackup.webframe.org> X-Provags-ID: V03:K1:A6b0tba/oAp5weeMv8Id0ewmFTq3R3vkbykP9bgoVIKjAeob3HV jzpPsWrjq9PHTS+15JCk4bSX1n2oDjVbRF9IQyKnrSoUji108QDDbEqRwMIYvgsKst8QrnT i1EAAp/s+L7QvQTpCQqvFrQVQlppw7mTQtu9Wqv2R8N+tKrTQnhf9w3pDJiSRXIWrWBocYL LnV+VZMq/a0cANK8h0Y3w== X-UI-Out-Filterresults: notjunk:1;V03:K0:45vLg10/rL8=:ebQJLdNNWH0wkmExdJH9Yd DTyzONWWXjj0E37kiABHc7cjCFwt3DELLUxZHlp7E/rlG1gW2cDwibr24xOD60Pzlu+Pnnnwu EV3wlJFvB6H7HtmsaRqvz14R9hbQ556mLEm0rI9aE6SOtr56mSlOWMXIKR1tBvU9nDcv6MWj1 PYLePuT2YwMgQJ97podMgenJ371cd8bbJYzaLDq8R1ff+0GibSyJIsA/y0GEuE5NgAwd/0Rk9 W6J2x22sdjiXkqtCWaejW4ErORX+WAwtP81TnXuh0IJlnhCXEnau7MOSBHOzAjLSaQljcJOx1 oIaWuYCB79xJlV0oqR4fbqP7LfEPUu/nc5qTKJmZjmD19ukxG83mP4NnhsQBTW51Zvf1ORTTA sfVtiS6qsa55jK+w7Q4d2HvCDzFcT1d0WUYuDpV3gmb13kBHN2GH1zpZeAclmXpPK75LAs31x lAXjl1hyjHWPD8oDzkXYVVkpu5KsSPe2+iAd9FTLI8Izh0WR63EVsUFMU3PmMxEnB4b68Gj8P BFvwOjKRtqTTD/5KDeZZlYQBpy4wwN6CPFfoHaVZFatRL//De1XkkGSc0bwRUClH6Gut4NKTa e5k16rGKL2KpdNg0p2YL/ZKLIo0xNO0QHdt7lZtyGMfjA3drd5CSaVTuiBnYQz6t6cd6ypTkj 7XYPNkwJqFTnTdgV9eAuzSXxr3SHACZg01SEn3CEddP0HJtc+bQcbyLkVS1T3/61M8PDqlKV9 y83oYntzHLVNjgKevp+Ei/UCM4eo1Qw5WOXSHvicZEn2k/bAvwok0h8czn42eUekFsVOhRbmL vt9sMkaXtNZCc2rRIqmCDL+QP5PORtAtJncqyqFRW/ttFdL9P3Bwr1+LH2ner8R8n9tS9FEl3 z4ajDkaEJ7KI2FKuXPuSyE6sgmE4HFxLEIzVE/Pz8ZlnmGRLWuav5LuJvVqsNN1j2M9h3fJE1 rEWulct5EPxw0Ng26s5kldqS3W/yZrsuSOGA3oFqRdNAdCItbxukHc9OHfq4DB7l9JuTGiw/v mleulzzIEYnv2Hk6030t6p3xVlLD1qP1oq5MPmY6xW5oN9yycIDL/ZgE1qI3idfBkYiK7xfTQ oeBGE/8LC7b6Ow= Received-SPF: pass client-ip=212.227.17.20; envelope-from=scdbackup@gmx.net; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH X-BeenThere: info-mtools@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2022 18:54:20 -0000 Hi, during the attempt to make the EFI bootable ISO images of project pcmemtest reproducible it turned out that mcopy yields different byte-level results in different timezones, although environment variable SOURCE_DATE_EPOCH is set to the same value. This is caused by the use of localtime(3) in function mk_entry() which interprets the overridden getTimeNow() value against the specification of SOURCE_DATE_EPOCH at https://reproducible-builds.org/specs/source-date-epoch/ which says that it holds the number of seconds in UTC. So in the special case that getTimeNow() is overridden by SOURCE_DATE_EPOCH, the conversion in mk_entry() of directory.c should be done by now = gmtime(&date2); instead of now = localtime(&date2); Now i wonder how one would properly transfer from misc.c to directory.c the information that the "now"-time was overridden. Two alternative approaches come to my mind: - Move the interpretation of SOURCE_DATE_EPOCH to config.c and store the value in two new global variables: A flag and a value. getTimeNow() would return the value if the flag says that it is valid. mk_entry() would use gmtime(3) if the flag says "valid". - Introduce a new function int haveSourceDateEpoch(int set_to_1) { static int have = 0; if (set_to_1) have = 1; return(have); } It would be called as haveSourceDateEpoch(1) in getTimeNow() if SOURCE_DATE_EPOCH is accepted. It would be called as haveSourceDateEpoch(0) in mk_entry() in order to decide whether to use gmtime(3). What does upstream say to these ideas ? Have a nice day :) Thomas From MAILER-DAEMON Tue Feb 22 17:40:56 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nMdq4-00026o-MT for mharc-info-mtools@gnu.org; Tue, 22 Feb 2022 17:40:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:55874) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMdpy-0001pi-Ey for info-mtools@gnu.org; Tue, 22 Feb 2022 17:40:50 -0500 Received: from lucifer.abilit.eu ([85.93.218.208]:44758) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nMdpu-0002BB-MV for info-mtools@gnu.org; Tue, 22 Feb 2022 17:40:49 -0500 Received: from mailout.lll.lu (unknown [10.10.13.1]) by lucifer.abilit.eu (Postfix) with ESMTPS id 04992E9033 for ; Tue, 22 Feb 2022 23:40:41 +0100 (CET) X-Envelope-To: Received: from [192.168.178.21] (vodsl-10249.vo.lu [85.93.207.9]) (authenticated bits=0) by lll.lu (8.15.2/8.15.2/Debian-22) with ESMTPSA id 21MMedLi2168461 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Tue, 22 Feb 2022 23:40:40 +0100 To: info-mtools@gnu.org References: <9613380351189766901@scdbackup.webframe.org> From: Alain Knaff Message-ID: <7097bb9c-548d-d635-52e0-619a46785bc9@knaff.lu> Date: Tue, 22 Feb 2022 23:40:39 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 MIME-Version: 1.0 In-Reply-To: <9613380351189766901@scdbackup.webframe.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Received-SPF: pass client-ip=85.93.218.208; envelope-from=alain@knaff.lu; helo=lucifer.abilit.eu X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, NICE_REPLY_A=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH X-BeenThere: info-mtools@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Feb 2022 22:40:51 -0000 Hi Thomas, On 17/02/2022 19:54, Thomas Schmitt wrote: > Hi, > > during the attempt to make the EFI bootable ISO images of project pcmemtest > reproducible it turned out that mcopy yields different byte-level results > in different timezones, although environment variable SOURCE_DATE_EPOCH is > set to the same value. > This is caused by the use of localtime(3) in function mk_entry() which > interprets the overridden getTimeNow() value against the specification > of SOURCE_DATE_EPOCH at > https://reproducible-builds.org/specs/source-date-epoch/ > which says that it holds the number of seconds in UTC. Weird, I just had a look at that page, and elsewhere it seems to imply that SOURCE_TIME_EPOCH should be formatted in the user's timezone: Formatting MUST be deferred until runtime if an end user should observe the value in their own locale or timezone. > > So in the special case that getTimeNow() is overridden by SOURCE_DATE_EPOCH, > the conversion in mk_entry() of directory.c should be done by > > now = gmtime(&date2); > > instead of > > now = localtime(&date2); > Should it? I guess it depends on which part of the document you give more weight... > > Now i wonder how one would properly transfer from misc.c to directory.c > the information that the "now"-time was overridden. > Two alternative approaches come to my mind: > > - Move the interpretation of SOURCE_DATE_EPOCH to config.c and store > the value in two new global variables: A flag and a value. > getTimeNow() would return the value if the flag says that it is valid. > mk_entry() would use gmtime(3) if the flag says "valid". This silently assumes that mk_entry is only ever called with current time (or time faked with SOURCE_DATE_EPOCH). However, if preserveTime is set, it might be called with the timestamp of the source file, and in that case, it should be formatted with localtime rather than gmtime. > > - Introduce a new function > int haveSourceDateEpoch(int set_to_1) > { > static int have = 0; > > if (set_to_1) > have = 1; > return(have); > } > It would be called as haveSourceDateEpoch(1) in getTimeNow() if > SOURCE_DATE_EPOCH is accepted. > It would be called as haveSourceDateEpoch(0) in mk_entry() in order > to decide whether to use gmtime(3). Same issue. It would mess up time formatting in case the time being formatted is not the current time (or current time faked via SOURCE_DATE_EPOCH). Properly implementing this would need to add a parameter to mk_entry to tell it whether to format the time as UTC or as local time, and it would be the *caller* of mk_entry which would call this haveSourceDateEpoch as appropriate. Or in some cases, it would be the caller of the caller... > > What does upstream say to these ideas ? IMHO, all this introduces way too much complexity for a use case which is rather niche. Why can't the pcmemtest project just set the TZ environment variable to UTC? After all, if your build process calls the "date" utility, you would have to do the same. > > > Have a nice day :) > > Thomas > Regards, Alain From MAILER-DAEMON Wed Feb 23 03:25:07 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nMmxO-0000C1-R9 for mharc-info-mtools@gnu.org; Wed, 23 Feb 2022 03:25:06 -0500 Received: from eggs.gnu.org ([209.51.188.92]:38596) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMmxN-0000BV-Cn for info-mtools@gnu.org; Wed, 23 Feb 2022 03:25:05 -0500 Received: from mout.gmx.net ([212.227.15.18]:55969) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nMmxK-0003CV-Be for info-mtools@gnu.org; Wed, 23 Feb 2022 03:25:05 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1645604698; bh=URlwztJBMD9A6oCNQVRNkfRZ++cXRWDK7ZbmPCC1Kwc=; h=X-UI-Sender-Class:Date:From:To:Subject:References:In-Reply-To; b=ARKFaqk6d15h4WYi+JBfrcBwzxta4IBh0l8tYzrWH1pnwea3AEV5nJf6Bui0DvK0r dO2deUm/b1Gh+zlp7tJAVgOTfkaPOoV+TizJrL5EQzkqwBcKN1NA1ntWHSddiZPEKZ RFFQWlF1bbQha5Z8DluoU4QV1eqWI5AkEgWM37Ro= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from scdbackup.webframe.org ([84.179.236.146]) by mail.gmx.net (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MhU9Z-1nrjqr1WL5-00eZGc for ; Wed, 23 Feb 2022 09:24:58 +0100 Date: Wed, 23 Feb 2022 09:25:36 +0100 From: "Thomas Schmitt" To: info-mtools@gnu.org Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable References: <7097bb9c-548d-d635-52e0-619a46785bc9@knaff.lu> In-Reply-To: <7097bb9c-548d-d635-52e0-619a46785bc9@knaff.lu> Message-Id: <25817380683452206179@scdbackup.webframe.org> X-Provags-ID: V03:K1:LfCoc9A7htjIDFk99BG+CaKfdtpiA8K/sYQkkraDeks1lVTdYho tCfJbJ4ko41POPHSOwL5RWaAIfCbX3XvyGcIKxDUH3FJZTZXy7Bc4ADOfj7kkTYD/GvBsdN 4oGgQaBRbC0OG1xbwXLuRDFXdlyv9z1p/tQW8Q0wd6ISOoLjCvHsWwGEy6y0bCGpILqHUs6 miPT/Q6GxgUBQKMhPvvng== X-UI-Out-Filterresults: notjunk:1;V03:K0:tIAmb5pfx/w=:58/Vq2Sl1wWG7TOowFNMd4 aRmSblXxU3aURkaStrr4uvoi6C1+cmRr95RshohsoQ/XFfkVAWMWd3y5Urua97T/DxMp0c6Wh 9oqz/1/i6AzAFAu9CtXv57Yjxb4PcJt5t6+WvsaT1I74q5bf2NLtykqimUjtPRADqSpvWWfLb 5QxVsSekUdrlHkfXDpGmwxsUxEhDcKLVVFI2LhFJm0coKOcdxUWzO/yFxZsLMs9cQ8VAEq0We yX6zuWYa3YaynUeKIJKtA66k8iHO2plPHDcdzGwSGrhwU0gAAcOBMXOj/MuuRkTRJq034q+G7 BQvAaWZPTDAMtQpN3woTuTaHute12Yu1UJY9xZW/nNWS7TCvg8hAyuR2sy4k1vDVvu8inXZ+9 SmJ8Dnbo293XwNgC1Q7YxJ1dFtOULFZJ3MSfprc5EebYzUzsF19uSoBnLDulHASTjEOKfZrDu tiFyzeORKJoke05TwMxyms5WpXtiOlBVRsxfUnjDylwTG6vys0BSaokcOEFMutRkpSPJV/MvK S2dPVPK5mGu25k683v0oqcC7WjNb5mqjxqSTvohA3jfSkPy69JxHytMDYOOD00XWptt7SQp4e CmYk4/uJtrF/lzFABqpe8QcAVOr5Wj86LQ3KNarc9clpiLOaweZBpiif7oV7uUaZmedN6n+fV Vm1Seo6yjX84fktgFGz9Z9sGGOdWecO4c7d/zQoZYmS2xsPyd+S+vDRnBlz0Z+yIHCE2fRqbB 0kfkTtXyxin3pqSlE7lgtoaJW9Xd/IptLIxvzBSDkrU0lqIrlaV377K3nzpCUfhUjDxfgl31s 9+Okh2Kc9mmIvNrm9j5thJdCabTg5eafAUqVr4Q8MObaitF9hzCEx15NCzgq/yArKXqniSGCu 9416IloAvQaVAlVn7VHfm+qbAbL7rZBxFNdz2cvZDdVYR6s0YX/iWkRG8QI3Ryu75mfkC+UYH oHevuV7J5npiq/aAaONfQyMKfQskzFx0FLg2VbXMOr2NMTYLxMt0D5GqJO9kKi71uGtmoTmHJ qvRmSfdDQJ1bMCVtEpNKI+0hcvB2D53ThLDe1qix5nufihp3lkzt4Ghxp5kaEP3fQnfzBzEK6 tllwz6y7fttYwk= Received-SPF: pass client-ip=212.227.15.18; envelope-from=scdbackup@gmx.net; helo=mout.gmx.net X-Spam_score_int: -27 X-Spam_score: -2.8 X-Spam_bar: -- X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action Subject: Re: [Info-mtools] mcopy applies local time zone to SOURCE_DATE_EPOCH X-BeenThere: info-mtools@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 08:25:05 -0000 Hi, Alain Knaff wrote: > Why can't the pcmemtest project just set the TZ > environment variable to UTC? Good question. At least this proposal was not made by Chris Lamb in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D1005197 which he started and where we found that mcopy applies the time zone. I will now add this proposal to that bug report. Maybe man mcopy should mention SOURCE_DATE_EPOCH and the need to also set TZ if the resulting filesystem image shall be globally reproducible. (I don't see such text in mtools-4.0.37/mcopy.1 ) =2D---------------------------------------------------------------------- So only interesting in case that TZ is in some way not the solution: > Weird, I just had a look at that page, and elsewhere it seems to imply > that SOURCE_TIME_EPOCH should be formatted in the user's timezone: > > Formatting MUST be deferred until runtime if an end user should > observe the value in their own locale or timezone. Yes. After boldly deriving the need for a globally standardized time zone from the word "UTF" i realized that the specs of reproducible.org shy away from time zone problems: "At present, we do not have a proposal that includes anything resembling a "time zone"." But if the creation of a FAT (or ISO 9660) filesystem shall be world-wide reproducible, then there has to be some specification of how to deal with time zones when converting SOURCE_DATE_EPOCH to Year/Month/Day/Hour/Minute/Seconds. The rule which you quoted might give a reason to do so: * FAT needs formatting of SOURCE_DATE_EPOCH. * One cannot do this at "runtime" of the FAT filesystem, which in the special case of pcmtest is when EFI reads the filesystem to find and run the \EFI\BOOT\BOOT*.EFI start program. =3D> So one must not let the end user see their own locale or timezone. > I guess it depends on which part of the document you give > more weight... Well, the weight is on the purpose of https://reproducible-builds.org "[...] to allow verification that no vulnerabilities or backdoors have been introduced during this compilation process. By promising identical results are always generated from a given source, this allows multiple third parties to come to a consensus on a =E2=80=9Ccorrect=E2=80=9D res= ult, [...]" Obviously encoding local time zones during the "compilation process" is spoiling this purpose. > > [my implementation ideas] > This silently assumes that mk_entry is only ever called with current > time (or time faked with SOURCE_DATE_EPOCH). However, if preserveTime is > set, it might be called with the timestamp of the source file, and in > that case, it should be formatted with localtime rather than gmtime. I had similar problems when implementing SOURCE_DATE_EPOCH in xorriso, which has to produce Year/Month/Day/Hour/Minute/Seconds/Timezone in the Volume Descriptors of ISO 9660. xorriso is intended to be entirely controlled by its commands, which can make and revoke particular program settings. My solution was to let SOURCE_DATE_EPOCH set the defaults but to allow xorriso commands to override these defaults. Those commands should of course be used with care when reproducible build of an ISO is desired. Chris Lamb was not fully happy with that solution. But it works well in practice. Nobody came yet to the idea to set SOURCE_DATE_EPOCH and then to use xorriso commands to override the default settings which it caused. In the same way, mcopy could take its option -m as reason to enable local time zone although SOURCE_DATE_EPOCH is present. > IMHO, all this introduces way too much complexity for a use case which > is rather niche. I would not call FAT filesystems for booting via EFI a niche case. :)) Have a nice day :) Thomas From MAILER-DAEMON Fri Feb 25 00:35:19 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nNTGA-0005s5-UE for mharc-info-mtools@gnu.org; Fri, 25 Feb 2022 00:35:18 -0500 Received: from eggs.gnu.org ([209.51.188.92]:45680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNTG4-0005pN-JU for info-mtools@gnu.org; Fri, 25 Feb 2022 00:35:13 -0500 Received: from luckmann.name ([213.239.213.133]:35459 helo=static.213-239-213-133.clients.your-server.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNTFm-0001FA-4g for info-mtools@gnu.org; Fri, 25 Feb 2022 00:34:58 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 502) by static.213-239-213-133.clients.your-server.de with local id 0000000000E54037.0000000062186A7A.000044BB; Fri, 25 Feb 2022 06:34:50 +0100 Date: Fri, 25 Feb 2022 06:34:50 +0100 From: Helge Kreutzmann To: info-mtools@gnu.org Message-ID: <20220225053449.GA24831@Debian-50-lenny-64-minimal> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="=_luckmann.name-17595-1645767290-0001-2" Content-Disposition: inline X-Public-Key-URL: http://www.helgefjell.de/data/debian_neu.asc X-homepage: http://www.helgefjell.de/debian User-Agent: Mutt/1.10.1 (2018-07-13) Received-SPF: none client-ip=213.239.213.133; envelope-from=debian@helgefjell.de; helo=static.213-239-213-133.clients.your-server.de X-Spam_score_int: 1 X-Spam_score: 0.1 X-Spam_bar: / X-Spam_report: (0.1 / 5.0 requ) BAYES_00=-1.9, CK_HELO_GENERIC=0.001, HELO_DYNAMIC_IPADDR=1.951, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_SBL_A=0.1 autolearn=no autolearn_force=no X-Spam_action: no action Subject: [Info-mtools] Issues in mtool manpages X-BeenThere: info-mtools@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 Feb 2022 05:35:13 -0000 This is a MIME-formatted message. If you see this text it means that your E-mail software does not support MIME-formatted messages. --=_luckmann.name-17595-1645767290-0001-2 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Dear mtools maintainer, the manpage-l10n project maintains a large number of translations of man pages both from a large variety of sources (including mtools) as well for a large variety of target languages. During their work translators notice different possible issues in the original (english) man pages. Sometimes this is a straightforward typo, sometimes a hard to read sentence, sometimes this is a convention not held up and sometimes we simply do not understand the original. We use several distributions as sources and update regularly (at least every 2 month). This means we are fairly recent (some distributions like archlinux also update frequently) but might miss the latest upstream version once in a while, so the error might be already fixed. We apologize and ask you to close the issue immediately if this should be the case, but given the huge volume of projects and the very limited number of volunteers we are not able to double check each and every issue. Secondly we translators see the manpages in the neutral po format, i.e. converted and harmonized, but not the original source (be it man, groff, xml or other). So we cannot provide a true patch (where possible), but only an approximation which you need to convert into your source format. Finally the issues I'm reporting have accumulated over time and are not always discovered by me, so sometimes my description of the problem my be a bit limited - do not hesitate to ask so we can clarify them. I'm now reporting the errors for your project. If future reports should use another channel, please let me know. Man page: mattrib.1 Issue: flags =E2=86=92 tags "mattrib - change MSDOS file attribute flags" "\\&\\&CW is used to change MS-DOS file attribute flags. It has th= e " "following syntax:" "\\&\\&CW adds attribute flags to an MS-DOS file (with the `\\&CW<" "+>' operator) or remove attribute flags (with the `\\&CW<->' operator)." -- Man page: mattrib.1 Issue: mformat =E2=86=92 \\&CW "Replay mode. Outputs a series of \\&CW commands that will " "reproduce the current situation, starting from a situation as left by " "untarring the MS-DOS file system. Commands are only output for attribute " "settings that differ from the default (archive bit set for files, unset fo= r " "directories). This option is intended to be used in addition to tar. The " "\\&CW attribute is not taken into account, as tar can set that o= ne " "itself." -- Man page: mcopy.1 Issue: (\\(ifname =E2=86=92 (see \\(ifname "No confirmation when overwriting Unix files. \\&CW doesn't warn th= e " "user when overwriting an existing Unix file. If the target file already " "exists, and the \\&CW<-n> option is not in effect, \\&\\&CW asks " "whether to overwrite the file or to rename the new file (see \\(ifname " "clashes\\(is) for details). In order to switch off confirmation for DOS " "files, use \\&CW<-o>." -- Man page: mkmanifest.1 Issue: Unix =E2=86=92 UNIX "The \\&CW command is used to create a shell script (packing " "list) to restore Unix filenames. Its syntax is:" "You want to copy the following Unix files to a MS-DOS diskette (using the = \\&" "\\&CW command)." "Suppose I've copied these files from the diskette to another Unix system, " "and I now want the files back to their original names. If the file " "\"manifest\" (the output captured above) was sent along with those files, = it " "could be used to convert the filenames." -- Man page: mkmanifest.1 Issue: makmanifest doesn't touch filenames with both lowercase and upper= case letters (see the example below, v4.0.26). "\\&\\&CW creates a shell script that aids in the restoration o= f " "Unix filenames that got clobbered by the MS-DOS filename restrictions. MS= -" "DOS filenames are restricted to 8 character names, 3 character extensions,= " "upper case only, no device names, and no illegal characters." -- Man page: mkmanifest.1 Issue 1: mkmanifest =E2=86=92 \\&CW Issue 2: Unix =E2=86=92 UNIX "The mkmanifest program is compatible with the methods used in \\&" "\\&CW and \\&CW to change perfectly good Unix filenam= es " "to fit the MS-DOS restrictions. This command is only useful if the target " "system which will read the diskette cannot handle VFAT long names." -- Man page: mkmanifest.1 Issue: Capitalization is obviously not of particular interest in the cur= rent mtools-4.0.26. Should be fixed in the man page (or even fixed in mtool= s itself). =20 "B< mv very_lon very_long_name\n" " mv 2xmany.dot 2.many.dots\n" " mv illegalx illegal:\n" " mv xprn.dev prn.dev\n" " mv capital Capital>\n" -- Man page: mmove.1 Issue: moves or renames =E2=86=92 move or rename "The \\&CW command is used to move or rename an existing MS-DOS file= " "or subdirectory." -- Man page: mpartition.1 Issue: mpartition =E2=86=92 B "The starting offset of the partition, expressed in sectors. If begin is no= t " "given, \\&CW lets the partition begin at the start of the disk= " "(partition number 1), or immediately after the end of the previous partiti= on." "The size (length) of the partition, expressed in sectors. If end is not " "given, \\&CW figures out the size from the number of sectors, " "heads and cylinders. If these are not given either, it gives the partitio= n " "the biggest possible size, considering disk size and start of the next " "partition." -- Man page: mpartition.1 Issue 1: mpartition =E2=86=92 \\&CW Issue 2: is not changes =E2=86=92 won't be changed "Usually, before writing back any changes to the partition, mpartition " "performs certain consistency checks, such as checking for overlaps and " "proper alignment of the partitions. If any of these checks fails, the " "partition table is not changed. The \\&CW<-f> allows you to override thes= e " "safeguards." -- Man page: mpartition.1 Issue: mpartition =E2=86=92 \\&CW "If the verbosity flag is given twice, \\&CW will print out a " "hexdump of the partition table when reading it from and writing it to the " "device." -- Man page: mpartition.1 Issue: within the 65536 sector =E2=86=92 within 65536 sectors "For all others, if the partition fits entirely within the first 65536 " "sectors of the disk, assign 0x01 (``\\&CW'') for FAT12 " "partition and 0x04 (``\\&CW'') for FAT16 partitions" -- Man page: mren.1 Issue: There's no difference between the current directory and the direc= tory which the mcd command reports; \\&\\&CW is superfluous "If the first syntax is used (only one source file), and if the target name= " "doesn't contain any slashes or colons, the file (or subdirectory) is " "renamed in the same directory, instead of being moved to the current \\&" "\\&CW directory as would be the case with \\&CW. Unlike the MS= -" "DOS version of \\&CW, \\&CW can be used to rename directories." Greetings Helge --=20 Dr. Helge Kreutzmann debian@helgefjell.de Dipl.-Phys. http://www.helgefjell.de/debian.php 64bit GNU powered gpg signed mail preferred Help keep free software "libre": http://www.ffii.de/ --=_luckmann.name-17595-1645767290-0001-2 Content-Type: application/pgp-signature; name="signature.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEbZZfteMW0gNUynuwQbqlJmgq5nAFAmIYanMACgkQQbqlJmgq 5nB6Nw/7BazsTV63UF3SbQ0sKKxXlwgSwKkdrehDypCa7/OmCWGP85UafT8W48CK SpEevbbN/pjLJkPJz+6qs88BMQPXMENBKiqAFmIOTiuWM68f3EKvFr9K7bH/KeOR HGGvG54Eo/0stXAQ5kpp2QFXy1Px4PCda5wSJ2/W6vAmNZ4PPQnM+ULFWH0UDnAv w9T89b22BLG9QjMOJi6c+fIEVz8Te5aCi1CbPwDhvuu5dN7Mvtwsj2F4e9MmXZWt 9NmoELQlnRyR30Ee5qtBzHL4DoalHdryIRRFLwg5xJ8k87Ey5IP2xoHXZYDA1IUT pE4MsSq3/3l94rkoXRSdMj1lTwilkT9pHw2VZpWtuL1u42itti/YPO25MlFwl3so TwK0pbw0FcRurYuaij3EH3kTGA6QipV10u/8D7YJZUfempCrx6tRdW5f0PkhMhfg MVqz9qZx2+YKH8ZKWq2pdZK3mXRyqMKorWh1ryFCIGCV7UCqQLA8gRBQYA1+JCpU HyXseNE/562alLWESCDZbi2g2F9NhnQ0cB5vSw4UVrzTR0xPlEhGwOPhlJ6zKpMg ItcaYcPRasTSxJk+8ol7KXS9geyACt0sS/ggv6EvkOLQIEuDglU6eiqb8xcm5rtb atP0or/fZ5SgroO6i6Bq82gVTjCKlGJh/wBRP1qCASK4jLwYXiQ= =V3I9 -----END PGP SIGNATURE----- --=_luckmann.name-17595-1645767290-0001-2-- From MAILER-DAEMON Sat Feb 26 08:00:39 2022 Received: from list by lists.gnu.org with archive (Exim 4.90_1) id 1nNwgh-0004sr-ER for mharc-info-mtools@gnu.org; Sat, 26 Feb 2022 08:00:39 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43414) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNwgg-0004rE-4b for info-mtools@gnu.org; Sat, 26 Feb 2022 08:00:38 -0500 Received: from [2a01:170:1012:77::25] (port=62030 helo=mail.sylvia-reinartz.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nNwge-0002Tu-5H for info-mtools@gnu.org; Sat, 26 Feb 2022 08:00:37 -0500 Received: from sylvia-reinartz.de (unknown [IPv6:2a01:170:1012:77:3a18:5cd3:dbf8:b429]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: is) by mail.bnhb484.de (Postfix) with ESMTPSA id 4488910AA0 for ; Sat, 26 Feb 2022 13:55:17 +0100 (CET) Date: Sat, 26 Feb 2022 13:53:31 +0100 From: Ignatios Souvatzis To: info-mtools@gnu.org Message-ID: References: <20220225053449.GA24831@Debian-50-lenny-64-minimal> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220225053449.GA24831@Debian-50-lenny-64-minimal> X-Host-Lookup-Failed: Reverse DNS lookup failed for 2a01:170:1012:77::25 (failed) Received-SPF: neutral client-ip=2a01:170:1012:77::25; envelope-from=is@netbsd.org; helo=mail.sylvia-reinartz.de X-Spam_score_int: -2 X-Spam_score: -0.3 X-Spam_bar: / X-Spam_report: (-0.3 / 5.0 requ) BAYES_00=-1.9, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action Subject: Re: [Info-mtools] Issues in mtool manpages X-BeenThere: info-mtools@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2022 13:00:38 -0000 Hello, On Fri, Feb 25, 2022 at 06:34:50AM +0100, Helge Kreutzmann wrote: > Man page: mattrib.1 > Issue: flags → tags > > "mattrib - change MSDOS file attribute flags" > > "\\&\\&CW is used to change MS-DOS file attribute flags. It has the " > "following syntax:" > > "\\&\\&CW adds attribute flags to an MS-DOS file (with the `\\&CW<" > "+>' operator) or remove attribute flags (with the `\\&CW<->' operator)." I'd rather suggest to change it to attribute *bits*, in line with the list of supported attribute bits a bit further in the page and with the language used in the chmod manual page. Regards, (also Dipl.Phys.) Ignatios Souvatzis