bug-fileutils
[Top][All Lists]
Advanced

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

Destroying files with 'cp'


From: Michel SIX
Subject: Destroying files with 'cp'
Date: Fri, 20 Sep 2002 20:23:36 +0200 (DFT)

                                           E-mail:  address@hidden

                                           Michel Six
                                           Departement de Geophysique Appliquee
                                           case 105
                                           Universite Pierre et Marie Curie
                                           4 Place Jussieu
                                           75252 Paris cedex 05
                                           France

                                           to <address@hidden>


                      Destroying files with 'cp'

I run Linux Slackware 8.1 distribution with fileutils-4.1-i386-2
Cpu is an AMD K6 3D processor

Although this is a shell-cp bug rather than a pure cp bug, (AIX korn shell
users also know it), I think that the script I use as a stop-gap should be
put somewhere in the cp software.

The facts are probably well known but here is a typical scenario:

 -you have a backup of a routine you are working on in, let us say a zip disk;
  i.e you have 2 files, the executable /zip/.../myfile and the source
  /zip/.../myfile.source
 -then you need to, for whatever reason, restart with the backuped files.
 -so you type "cp /zip/.../myfile*", forgeting the ".".
 ( Of course you should not forget the dot, but you have been using for years
   non-unixes where the default is your working directory; and besides it can
   happen that you did make a typo)
 -now the /zip/.../myfile.source is just a copy of /zip/.../myfile.

If you did the backup from another computer you are safe, but otherwise...

The immediate reason is the shell (bash in my case) expansion, but a more
fundamental one is that 'cp' has two different meanings, and such a thing
in my opinion is a sure way to produce catastrophic results.

Strongly worded expletives being of no use, I decided to create a 'copy' script
that would be used as a pre-processor to 'cp'.
Fortunately in the "teletype unix days" the name 'copy' was not used because it
was too long a word!..., and for non-unixes it is the standard command.

Here is the bash script:
------------------------------------------------------------------------
y=$(history 1 | awk '{x = NF} ; {if($x ~ /[*?{~]/) {print 1} else {print 0} }')
if [ $y = 0 ]
  then
    y="eval cp -v -p $@"
    $y
  else
   echo "Copy: cowardly refusing to execute that incomplete command."
  fi
------------------------------------------------------------------------
(warning worded from the tar one)

The idea is to check just the last argument of the command (you can thus
include in the copy command any options you think of).
The last argument, for both acceptions of "cp", be it a file or a directory,
should not contain any expansion characters (hope I put all of them).

Note that this script will also save you for the case of 3 or more files with
the same prefix and the last expanded name being a directory.
The other cases are caught by the "...not a directory" protection mechanism.

Since then I don't use expletives (I still use some but not for that case)


The same problem occurs with 'mv' but I find it less common, probably because
non-unixes use rename. I nevertheless did a 'move' command along the same lines.
Here is the bash script:
------------------------------------------------------------------------
y=$(history 1 | awk '{x = NF} ; {if($x ~ /[*?{~]/) {print 1} else {print 0} }')
if [ $y = 0 ]
  then
    y="eval mv -v $@"
    $y
  else
   echo "Copy: cowardly refusing to execute that incomplete command"
  fi
------------------------------------------------------------------------



The third case is copying a file into a soft link. I think that by default
it should be forbidden and one should get a warning.
At present the contents of the linked file are replaced by those of the
copied file, and the name remains the same.

Maybe someday somebody -maybe you- will use bona fide the file...





reply via email to

[Prev in Thread] Current Thread [Next in Thread]