Re: cp --preserve=mode not right on rh4 and nfs

bug-coreutils

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: cp --preserve=mode not right on rh4 and nfs

From:	Warren L Dodge
Subject:	Re: cp --preserve=mode not right on rh4 and nfs
Date:	Sat, 4 Oct 2008 14:00:48 -0700

I resent this with all the attachments compressed


>  From: Jim Meyering <address@hidden>
>  Cc: address@hidden
>  Date: Sat, 04 Oct 2008 09:17:18 +0200
>  MIME-Version: 1.0
>  Content-Type: text/plain; charset=us-ascii
>  
>  Warren L Dodge <address@hidden> wrote:
>  > I have built coreutils-6.12 on a GNU/Linux RedHat3 system. When I use
>  > the "cp" command with the --preserve=mode,timestamps switch there is a
>  > problem where a copy to a nfs mounted file system does not set the
>  > timesamp properly.
>  >
>  > I show examples below where I run the command on GNU/Linux RedHat3 and it
>  > works as expected. Then I run the same binary on GNU/Linux RedHat4 and
>  > it does not work properly.

>  Thank you for the fine report.
>  
>  This does sound like a bug...
>  The problem is that you configured and built on one type of system
>  and ran the executables on a different type.  While in general that's
>  ok, there are some configure-time tests that detect OS bugs and
>  work around them (or features, and take advantage of them), and
>  in unusual cases, that can lead to trouble.
>  So if it found/enabled something on the system where built, yet
>  that bit failed (without run-time recourse) on the different system
>  where it was run, ...
>  
   I have since built coreutils-6.12.208-2441 on both RedHat3 and
   RedHat4 and get the same behavior.

>  
>  Obviously, we try not to have many pieces like that, but it can
>  happen, especially when someone builds on a newer system and tries to
>  run the resulting binary on an older one.  *That* is not supported
>  at all.  But you didn't do that.
>  
>  In your case, if you provide some more info, it may help:
>    - strace one of the losing cp commands (on RHEL4)
>    - strace the same, working cp command (on RHEL3)
>    - lib/config.h from your coreutils build directory on RHEL3
>  
   I am attaching the following files. Probably too many but it provides
   all the directions of nfs and /tmp that apply for the compiled
   coreutils and the OS provided coreutils.

    coreutils-6.12.208-2441_i686_linux2.4___config.h RedHat 3 build
    coreutils-6.12.208-2441_i686_linux2.6___config.h RedHat 4 build
    
    Run on GNU/Linux RedHat4 and built on same.
    
    6.12.208-2441_2.6_nfs_nfs.strace.out nfs to nfs 
    6.12.208-2441_2.6_nfs_tmp.strace.out nfs to tmp
    6.12.208-2441_2.6_tmp_nfs.strace.out tmp to nfs
    6.12.208-2441_2.6_tmp_tmp.strace.out tmp to tmp
    
    Run on GNU/Linux RedHat3 and built on same.
    
    6.12.208-2441_2.4_nfs_nfs.strace.out nfs to nfs
    6.12.208-2441_2.4_nfs_tmp.strace.out nfs to tmp
    6.12.208-2441_2.4_tmp_nfs.strace.out tmp to nfs
    6.12.208-2441_2.4_tmp_tmp.strace.out tmp to tmp
    
    /bin/cp GNU/Linux RedHat4 version 5.2.1
    
    bin_cp_2.6_5.2.1_nfs_nfs.strace.out nfs to nfs
    bin_cp_2.6_5.2.1_nfs_tmp.strace.out nfs to tmp
    bin_cp_2.6_5.2.1_tmp_nfs.strace.out tmp to nfs
    bin_cp_2.6_5.2.1_tmp_tmp.strace.out tmp to tmp
    
    /bin/cp GNU/Linux RedHat3 version 4.5.3
    
    bin_cp_2.4_4.5.3_nfs_nfs.strace.out nfs to nfs
    bin_cp_2.4_4.5.3_nfs_tmp.strace.out nfs to tmp
    bin_cp_2.4_4.5.3_tmp_nfs.strace.out tmp to nfs
    bin_cp_2.4_4.5.3_tmp_tmp.strace.out tmp to tmp

> 
> I believe I reported this quite some time ago. I was hoping the problem
>  > was solved in coreutils-6.12 as some of the users are needing this
>  > functionality.
>  
>  If you filed a bugzilla (http://bugzilla.redhat.com/),
>  please tell me the number.  If not, doing so (and merely referencing this
>  thread: http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/14699) may
>  also accelerate the processes.
>  

Here is my bug that was submitted

http://lists.gnu.org/archive/html/bug-coreutils/2007-08/msg00056.html

As noted in these conversations is that touch works properly. I also saw
the untarring a tar file keeps that proper timestamp.


It is suggested in there that it is an nfs bug of some sort on either
the client or the server. This is beyond what I know and any help in
pursuing that issue would be appreciated. We are using a large NetApp
filer which I would assume is knowledgeable of nfs but you never know. 


>  Also, using the RHEL3 binaries, can you run "make check"
>  on a RHEL4 system to see if any regression tests fail?
>  
   I did this and it seems to pass. It did however recompile a lot of
   the test files as it ran. I am not sure what trigered that.


>  > The /tmp on my machine is the local drive. The installed_tree/bin is
>  > where I am executing the command. The installed_tree is a nfs mounted
>  > file system. It is served by a NetApp system.
>  >
>  > coreutils-6.12 built on gnu/linux RedHat3
>  >
>  > 
> #############################################################################
>  > execute on GNU/Linux RedHat4
>  >
>  > ./cp --preserve=mode,timestamps --no-preserve=ownership yes z
>  > ./cp --preserve=mode,timestamps --no-preserve=ownership yes /tmp/z
>  > ./cp --preserve=mode,timestamps --no-preserve=ownership /tmp/z zz
>  > ./cp --preserve=mode,timestamps --no-preserve=ownership /tmp/z /tmp/zz
>  >
>  > ll yes /tmp/z /tmp/zz z zz
>  >
>  > -rwxr-xr-x  1 wdtmgr wdtmgr 73211 Oct  3 12:02 yes
>  > -rwxr-xr-x  1 wdtmgr wdtmgr 73211 Oct  3 12:02 /tmp/z
>  > -rwxr-xr-x  1 wdtmgr wdtmgr 73211 Oct  3 12:02 /tmp/zz
>  > -rwxr-xr-x  1 wdtmgr wdtmgr 73211 Oct  3 12:07 z         << WRONG TIME
>  > -rwxr-xr-x  1 wdtmgr wdtmgr 73211 Oct  3 12:08 zz        << WRONG TIME
>  ...
>  
>