Nanosecond timestamp truncated to 000000000, breaks build scripts

Bug #685392 reported by Razvan Surdulescu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
eCryptfs
New
Undecided
Unassigned

Bug Description

1). Short description:

The ext4 nanosecond timestamp on the Makefile generated by configure is truncated to 000000000 on my ecryptfs filesystem. This causes the Makefile to appear newer than the configure script, which means that the Makefile is generated twice (once during the first call to ./configure, and once again during make). This breaks some build wrapper scripts, like crosstool-ng (http://ymorin.is-a-geek.org/projects/crosstool), which patch the Makefile between the call to ./configure and the subsequent call to make. The bug does not happen on a regular ext4 (non-ecryptfs) filesystem, where the Makefile is only generated once, and the patch process is not overwritten later.

2). Environment:

Fresh install of Ubuntu 10.10.
$ uname -a
Linux XXX 2.6.35-23-generic #41-Ubuntu SMP Wed Nov 24 10:18:49 UTC 2010 i686 GNU/Linux

Home partition mounted with ecryptfs, as configured by the Ubuntu installer:
$ mount | grep ecryptfs
/home/XXX/.Private on /home/XXX type ecryptfs (ecryptfs_sig=YYY,ecryptfs_fnek_sig=ZZZ,ecryptfs_cipher=aes,ecryptfs_key_bytes=16)

3). How to reproduce the bug

Download and expand the sourcecode for binutils-2.19.1 from http://ftp.gnu.org/gnu/binutils/, in two different places -- one on /home/XXX (with ecryptfs), and another in /tmp/YYY (without ecryptfs):

$ cd /home/XXX
$ tar jxvf binutils-2.19.1.tar.bz2

$ cd /tmp/YYY
$ tar jxvf binutils-2.19.1.tar.bz2

Configure and generate the libiberty Makefile, first on ecryptfs:

$ cd /home/XXX/binutils/2.19.1
$ ./configure
$ make maybe-configure-libiberty

Now do the same on the regular (non-ecryptfts) partition:

$ cd /tmp/YYY/binutils/2.19.1
$ ./configure
$ make maybe-configure-libiberty

Look at the timestamps on the ecryptfs partition, in particular notice that the timestamp for the Makefile is truncated, and appears newer than the timestamp for config.status (which causes the Makefile to be re-generated later, and breaks the patch):

$ ls -l --full-time /home/XXX/binutils/2.19.1/libiberty/config.status /home/XXX/binutils/2.19.1/libiberty/Makefile
-rwxr-xr-x 1 XXX XXX 49031 2010-12-04 21:09:31.487142002 -0800 libiberty/config.status
-rw-r--r-- 1 XXX XXX 42846 2010-12-04 21:09:31.000000000 -0800 libiberty/Makefile

In contrast, the timestamps on the regular (non-ecryptfs partition) are as expected, where Makefile is older than config.status:

$ ls -l --full-time /tmp/YYY/binutils/2.19.1/libiberty/config.status /tmp/YYY/binutils/2.19.1/libiberty/Makefile
-rwxr-xr-x 1 XXX XXX 49004 2010-12-04 21:10:29.875142002 -0800 libiberty/config.status
-rw-r--r-- 1 XXX XXX 42846 2010-12-04 21:10:30.031142002 -0800 libiberty/Makefile

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.