Problem with mv command and touch command

Hi guys,

first of all I would say that this is my first time I write in a Forum.
I've read the "forum rules" and I hope i will respect them.
I searched everywhere for the solution of my problem but I didn't find anything.
Here my problem:
I'm using a sap job scheduler: in a particular job there are two main steps (scripts) that are based on unix command mv (first step) and touch command (second step/script): the first script (step) called "movedate.sh" uses a mv command to rename a file: it appends the current date and time to the name of the file, after the same script moves the file to another directory (using always the same "mv" command).
The second main step is a script based on a "touch" command: it finds out if the original file (without the date appended to his name) exists in the original folder, and if not, it tries to re-create it.
The first step goes ok (in fact you can see the file archived in the destination directory with the time stamp added to its name), but even if this step goes ok, the second one (that tries to create the file) goes in error because it says that the original file exists (as if the time-stamp was not added to the name of the file! But I can see the file archived with time-stamp in a different folder!)
The size of the file is few KB, the touch command occurs 10 seconds after the file has been archived (I use the time stamp appended to the name of the file as a time-reference).
The file system is shared.
So I "changed" the movedate.sh script, it does the same operations, but there are some checks that it performs: it checks if the time stamp has been added to the name, and it checks if the file with the time-stamp is located in the destination directory (if ok it means that it has been moved!)
So I have not no more errors... It seems to me that these checks act as a "refresh". Does it depend on the structure of the file system (as I said it's shared between three different servers)?
Any ideas why does this occur?
Thanks in advance for the replies.

Bye
Antonio :slight_smile:

Are these 2 steps defined separately into the SAP job, or are these steps direclty defined/called from your script, please show the code.

Help us to help you : show us the code of your 2 step then people could provide an more accurrate help.

Each one of these 2 step run an external command (in this case unix scripts), so the behavior should be like you were running these scripts from shell.

The code of the original movedate.sh is :

#!/bin/sh

usage()
{
    echo "USAGE: $0 <file1> <file2>";
    echo "    sposta il file <file1> nel file <file2>.";
    echo "    Il file <file2> non deve esistere.";
    echo "";

    case $1 in
        2) echo "Numero errato di parametri: $#";;
        3) echo "Il file <file2> non deve esistere";;
        4) echo "File non trovato";;
        *) echo "Errore non documentato";;
    esac

    echo "Return code $1";
    exit $1;
}

#echo $ORACLE_SID

# set the default_path where the parametres of the scripts should be located

DEFAULT_PATH=/usr/sap/${ORACLE_SID}/ifr
DATE_TIME=$(date +%Y%m%d%H%M%S)

# If the number of the parametres are not correct, exit with error

if [ ! $# -eq 2 ] ; then
    echo $#
    usage 2
fi

# If file <file2> exists, exit with error
if [ -f $DEFAULT_PATH/$2 ] ; then
    usage 3
fi

#origin path where the file is
path1=$DEFAULT_PATH/$1

#destination path where the file shold be moved
path2=$DEFAULT_PATH/$2

#If the file that has to move does not exist, exit with error.
if [ ! -f $path1 ] ; then
    usage 4
fi

for file in $path1; do
        mv $file $file$DATE_TIME
        
        #origin path without the name of the file
        path_1=${path1%/*}
        
        #destination path without the final "/"
        path_2=${path2%"/"}
        
        #confrontation of destination path and origin path, if different the file is moved, otherwise only the time and date is added to the name of the file.
            if [ ! $path_1 = $path_2 ]; then  
                mv $file$DATE_TIME $DEFAULT_PATH/$2
                echo "Moving the file " $file "... done!"
                else echo "origin path and destination path are the same, only time stamp added to the file... done!"
            fi    
done

----End of script---

I used a for cycle because mmv command because it isn't.
In default_path there is the variable ORACLE_SID, so only particular users can run the script (only who has this environment variable set)

The touch script called "ytouch.sh" does the following things:

#!/bin/sh
.
#other stuff, setting default_path and usage like number of parametres passed to the scripts
.
.
.
#check if the file that has to be created already exists
if [ -f $DEFAULT_PATH/$1]; then
     usage 3  #exit with error
fi

touch $DEFAULT_PATH/$1

1) When you call your script, are your $1 and $2 always a filename or is $2 sometimes a directory ?

2) Do your $1 and $2 may contains some "/" ?

For example, do you make some call such as:

./YourScript ./something/file1 ./other/relative/path/file2

or

./YourScript ./something/file1 ./other/relative/path/

??

Thanks for the reply;

1) $1 is the filename and $2 is the destination folder (and it does not contain the destination name of the file)

2) Yes the file contains some "/": for example (launching with the correct user):

./movedate.sh otherdirectory/file1 some_other_directory/

so it is like (because of DEFAULT_PATH):

./movedate.sh /usr/sap/${ORACLE_SID}/ifr/otherdirectory/file1 /usr/sap/${ORACLE_SID}/ifr/some_other_directory/

But you don't write the destination name of the file (because it is interpreted as another folder)

I would like to say that the script itself works fine, it has been fully tested, and it is used from various jobs, but there's a particular job that uses the combination of these two scripts (movedate.sh and ytouch.sh: ytouch.sh runs after movedate.sh and only if the previous one goes ok).

By putting some checks (simple if statements) in the movedate.sh script i do not receive no more errors: these checks (that should be redundant, because if the script orders to move the file, I presume that the file has been moved, in fact I can see it in the destination directory) tries to see :

a) if the timestamp has been added to the name of file1
b) if there is the file1 with the timestamp in the destination folder.

The movedate.sh returns no error only if these two if statements are true.
But as I said these two statements should be redundant, because the movedate.sh returned no error also when these "if conditions" were not put in the script, but in this case ytouch.sh went always in error because it found the file "file1" in the origin directory as if neither the timestamp was added to the file.

thank you for your reply and time spent to help me understanding this :slight_smile:

If you call your script like this :

./movedate.sh /usr/sap/${ORACLE_SID}/ifr/otherdirectory/file1 /usr/sap/${ORACLE_SID}/ifr/some_other_directory/

Then your

path1=$DEFAULT_PATH/$1

will contains :

/usr/sap/${ORACLE_SID}/ifr/usr/sap/${ORACLE_SID}/ifr/otherdirectory/file1

So you should not call your script that way , but you rather should call it using only the filename and directory name without specifying the path, since you set it up later on with the DEFAULT_PATH.

---------- Post updated at 03:25 PM ---------- Previous update was at 02:19 PM ----------

[[ -f "$DEFAULT_PATH/$1" ]] && [[ -d "$DEFAULT_PATH/$2" ]] && mv $DEFAULT_PATH/$1 $DEFAULT_PATH/$2/$1.$(date +%Y%m%d)

a) Where do you want this *.date file be generated ? in $DEFAULT_PATH or in DEFAULT_PATH/$2 ???

b) The file won't exists since it has been moved ... why don't you just copy it instead or moving it ... so you would let an original copy and avoid this additional step.

c) In the archive destination ? so you want it to be moved to $DEFAULT_PATH ? or $DEFAULT_PATH/$2 ????

d) Try to create which file and where ?

e) Are you trying to make a script that can be launched several time in parallele (concurrent run) ?

f) let's forget the touch part , i first need to understand what is the expected behaviour (please focus on describing the needs, not what you have done, but what is intended)

I think that instead of explaining what you did or how what you did works,
I just need to know : what are the needs (pseudo-code) ?

a). rename $1 with $1.date (all within the same $DEFAULT_PATH directory)
b). archive (move) the $1.date file into the $DEFAULT_PATH/$2 directory ?
c). other ???

Thx

---------- Post updated at 03:29 PM ---------- Previous update was at 03:25 PM ----------

by the way, as far as i understand, your
path_1 will always have the same value as $DEFAULT_PATH so $path_1 is useless : use $DEFAULT_PATH instead.

Thanks for your reply;
I cannot decide if to make a copy of the file or not, this particular file contains particular data of the current day, so it has to be archived in another directory before re-creating it.

a) I want (in this case) this file generated in $DEFAULT_PATH/$2, but this script is used by other jobs: in other cases (other jobs) the script takes the file (another file) and archives it (archiving: i mean appending the current time and date) in the same folder where the file is located (so sometimes it acts only as a "rename".

b) I know that file has just been moved to another location, but also this script (touch) is used in other situations: in other situations you must now if a particular file exists or not, because the presence/absence of the file influences the behavior to assume (so you must have scripts that can be usable in different situations)

c) I want this file moved in $DEFAULT_PATH/$2 (but as i previously said, in other situations the archive can occur in the same folder,I mean the origin folder, because the same script is used)

d) the touch script tries to re-create the file with its original name (I mean without timestamp) in the origin folder, for example:

origin folder: /usr/origin_folder/
file to archive : fileA (so you have /usr/origin_folder/fileA)
archive destination /usr/destination_folder/

-> at the end you must have /usr/destination_folder/fileA<date_time> (ex: fileA20110329161000 (2011 03 29 16.10.00)

e) after you have to re-create /usr/origin_folder/fileA, because this file should be processed by other programs, and archived at the end of the day. The day after, the programs that insert data into the file must find this file in the specific folder (so after archiving it you have to re-create it), and so on..

The needs of code are, as you said:

a) rename $1 in $1<date> (or $1.date it's the same) in the origin folder.
b) archive (mv) $1<date> in $DEFAULT_PATH/$2 (in this case; in other cases the script must archive the file in the same directory where the file is located, so i put a confrontantion of origin folder and destination folder, and if they are the same, only a rename (step a) occurs.
c) In this case i have to re-create the file that has just been archived ( I cannot put the touch command inside the movedate script because the script is used in other situations where the file to archive is not created but is uploaded or send by other systems). But for this, i think i can use a simple touch command.

So the needs are a) and b)

Thank you!

Ok sry i am completly lost.
you first state :
a) I want (in this case) this file generated in $DEFAULT_PATH/$2
and at the end you say :
a) rename $1 in $1<date> (or $1.date it's the same) in the origin folder

which is already amiguous : you want it in DP (DEFAULT_PATH) OR in DP/$2, not both .

If you are trying to modify a script that is already used by some other job, i would say it is not a good idea : you should do a re-engineering of the whole process (at least, that would be the clean way of doing things) to make your need clear before implementation OR create a completly new script so that what you code is independant of what already exists and thus has (or should have) no impact on it.

If you plan to modify an already running script , you should then first see what does the other job, in which case they do what, and take it into account in your new implementation... of course you shoud also make sure that submitting your new script in production would not introduce inconsistencies / discrepancies in the existing workflow.