scp and SGI DMF

Rick Jones rick.jones2 at hp.com
Thu Mar 2 05:18:45 EST 2006


Peter Stuge wrote:
> Can you test what rcp does? The general intention for scp is that it
> should behave the same way rcp does, if rcp truncates then scp may
> quite possibly change.

FWIW, this is a system call trace of an rcp under HP-UX 11.11 (11iv1) 
wen rcp was asked to copy a remote file to /tmp/foobie.  I'm just 
showing those things accessing the /tmp/foobie file:

stat64("/tmp/foobie", 0x7a0018b8) ........................ = 0
                             st_dev: 64 0x000003
                             st_ino: 121698
                            st_mode: S_IFREG|0755
                           st_nlink: 1
                            st_rdev: 0
                            st_size: 19016840
                         st_blksize: 8192
                          st_blocks: 18576
                             st_uid: 8394
                             st_gid: 20
                           st_atime: Wed Mar  1 10:05:45 2006
                           st_mtime: Wed Mar  1 10:05:47 2006
                           st_ctime: Wed Mar  1 10:05:47 2006
open("/tmp/foobie", O_WRONLY|O_CREAT|O_LARGEFILE, 0) ..... = 5

It then drops into a read/write loop writing the file.

I can make no assertions as to whether HP-UX's rcp is unique in its 
behaviour.  However, from the looks of things, it would be "OK" to add 
O_TRUNC because at the very end of the copy, rcp does this:

read(4, "\0\0\0\0\0\0\004\005abf312\0\00f".., 11400) ..... = 11400
write(5, "\0\0\0\0\0\0\004\005abf312\0\00f".., 11400) .... = 11400
ftruncate64(5, 19016840) ................................. = 0
sigvec(SIGINT, 0x7a00a6f8, 0x7a00a704) ................... = 0

which means that it is truncating the file to the length of the new 
version anyway.

rick jones

  Hewlett-Packard Company            - 1 -   HP-UX Release 11i: November 
2000

  open(2) 
open(2)

            O_CREAT        If the file exists, this flag has no effect,
                        except as noted under O_EXCL below.  Otherwise,
                        the owner ID of the file is set to the effective
                       user ID of the process, the group ID of the file
                       is set to the effective group ID of the process if
                          the set-group-ID bit of the parent directory is
                           not set, or to the group ID of the parent
                         directory if the set-group-ID bit of the parent
                           directory is set.

                      The file access permission bits of the new file
                           mode are set to the value of mode, modified as
                           follows (see creat(2)):

                      +  For each bit set in the file mode creation mask
                         of the process, the corresponding bit in the
                         new file mode is cleared (see umask(2)).
                      +  The "save text image after execution" bit of
                         the new file mode is cleared.  See chmod(2).

                      +  On HFS file systems with access control lists,
                         three base ACL entries are created
                         corresponding to the file access permissions
                         (see acl(5)).

                           +  On JFS file systems that support access
                              control
                              lists, optional ACL entries are created
                              corresponding to the parent directory's
                              default ACL entries (see aclv(5)).

            O_EXCL         If O_EXCL and O_CREAT are set and the file
                           exists, open() fails.

            O_LARGEFILE    This is a non-standard flag which may be used 

                           by 32-bit applications to access files larger
                           than 2 GB.  See creat64(2).

...

            O_TRUNC        If the file exists, its length is truncated 
to
                           0 and the mode and owner are unchanged.





More information about the openssh-unix-dev mailing list