Chapter 6 - Package Management - Explain why 'install' is generally safer than 'cp'

I took a look at the install.c source and the cp.c source. They both do extensive error checking, but when it comes down to the final operation, both call the same library routine: copy()

My review has persuaded me that install is not safer than cp. The install utility is merely a convenience for installers to copy the file, make prerequsite directories, set permissions and ownership, etc all with one command.

I could find no references in either install or cp that try to determine if a file (library) is already loaded in memory. Indeed, the operating system handles that issue automatically and does not actually remove the old file until all open references to it are closed, even though the entry may be removed from the directory structure.

The simple am most correct way to address this ticket is to merely remove third bullet in section 6.3.1.

install is safer than cp with the default options. The difference is that install always removes the destination file if it exists instead of overwriting. cp defaults to overwriting, this can be changed by --remove-destination, though.

Overwriting a running binary can have weird effects, AFAIK. If the file gets removed and recreated, everything is fine as the kernel keeps the old unchanged file around.

So overwriting vs. removing sounds like cp maintains the same inode and install does not. Is this correct?

Looks like both uses the same inode here, even if the file has been altered.

$ /bin/cp -vf inotify.h foo/ && ls -li foo/* && sleep 1 && echo >> inotify.h && /bin/cp -vf inotify.h foo/ && ls -li foo/*
`inotify.h' -> `foo/inotify.h'
574324 -rwxr-xr-x  1 dnicholson dnicholson 4218 2006-05-02 14:49 foo/inotify.h
`inotify.h' -> `foo/inotify.h'
574324 -rwxr-xr-x  1 dnicholson dnicholson 4219 2006-05-02 14:49 foo/inotify.h
$
$ /bin/install -v inotify.h foo/ && ls -li foo/* && sleep 1 && echo >> inotify.h && /bin/install -v inotify.h foo/ && ls -li foo/*
`inotify.h' -> `foo/inotify.h'
574324 -rwxr-xr-x  1 dnicholson dnicholson 4219 2006-05-02 14:50 foo/inotify.h
`inotify.h' -> `foo/inotify.h'
574324 -rwxr-xr-x  1 dnicholson dnicholson 4220 2006-05-02 14:50 foo/inotify.h

Always uses inode 574324.

cp --remove-destination also uses the same inode I just found out. So how does the kernel reference a deleted, but not-overwritten file that is currently in memory? I thought it was by the inode.

Oh. Mr Archaic. I know! I know!

When a file is deleted, the directory is updated and the reference count deleted by one. Only when the reference count goes to zero is the data that inode points to deleted. This happens when the file is closed by the last using program, not when the deletion operation occurs.

I am at a loss trying to find a link on the web regarding this. I'm google-challenged apparently. ;)

I thought I answered this a few days ago, bit I can't find the post. I reviewed the cource code to both install and cp. Both do extensive error checking, but in the end both call a common routine, copy, to actually put the destination file in place. From my review, I am convinced that install is not *safer* than cp, but is a convenience for installers in that it copies and can set permissions and owner/group with one command. Of course there are other switches that are different too, but the safety issue is not there.

One comment is that libraries in use are handled better by install. Not so. If you copy over a file that is in use, the inode is updated in the directory, but the original open file is not deleted until the last process that has the file open terminates. There is nothing in install that checks to see if a file is in use.

Ok, then by the fact that I trust your assessment and can't find anything on google, I will go ahead an remove that note in the book. Juerg, if you have information that disproves Bruce's assesment, please re-open the bug and provide the information.

I removed the warning about install being safer than cp in r7581.

Based on practical experience, install *is* safer than cp. Let me explain the problem that I ran into. I had started KDE. qt was installed in /usr. I was recompiling Qt in an xterm. The Qt Makefiles use cp instead of install. During installation, the qt libraries were replaced by the new versions which caused my KDE session to abort. When I replaced the cp in the Makefiles by install, everything was ok.