Hide Forgot
Description of problem: Touch a file with time stamp before epoch in NFS mount, eg. touch -t 196001010101 /mnt/nfs/testfile, NFS will store the time as 2096-02-06 07:29:16.000000000 Version-Release number of selected component (if applicable): kernel-2.6.18-299.el5 How reproducible: always Steps to Reproduce: 1. mount -t nfs localhost:/nfsexport /mnt/nfs 2. touch -t 196001010101 /mnt/nfs/testfile 3. stat /mnt/nfs/testfile or stat /nfsexport/testfile Actual results: [root@ibm-x3550m3-05 ~]# stat /mnt/nfs/testfile File: `/mnt/nfs/testfile' Size: 0 Blocks: 0 IO Block: 1048576 regular empty file Device: 19h/25d Inode: 1186558 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2096-02-06 07:29:16.000000000 -0500 Modify: 2096-02-06 07:29:16.000000000 -0500 Change: 2011-12-01 01:21:54.885728294 -0500 Expected results: time stamp before epoch Access: 1960-01-01 01:01:00.000000000 -0500 Modify: 1960-01-01 01:01:00.000000000 -0500 Change: 2011-12-01 01:21:19.648699182 -0500 Additional info: RHEL6 also has this issue
Meh, it's probably worth fixing and doing so appears to be trivial. We just need to backport: commit 042ad0b398ea4e937e38324dd096bdf9d2c495f7 Author: Bryan Schumaker <bjschuma> Date: Fri Apr 19 16:09:37 2013 -0400 nfs: Send atime and mtime as a 64bit value
I just noticed that this is a RHEL5 bug. Yeah, I don't see a good case for fixing this there, I'll close this one WONTFIX but clone it for RHEL6.
Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.