mv in a .sh script
 

There is a .sh script that scp's all files in a folder to another server, then the next line is a mv for * to another folder, which actually doesn't exist anymore.

1) will that mv to a non-existing folder just delete the file?
2) assuming #1 is true, if a file won't delete until the person who put it there deletes it manually, would there be a log file somewhere that tells me how/why he's dropping the file in there with the wrong permissions, or what the problem really is when this script runs?

If the target doesn't exist, the files won't go anywhere. It will show an error saying the target destination isn't valid.

where would I see that error though, since the .sh is ran by crontab every few minutes?

something is deleting the files, so it must be another cron job somewhere else if that's the case.

Typically, if a shell script run by cron emits any text on stdout or stderr, the text will be either logged onto the system log or e-mailed to the script owner. People normally deal with this by suppressing text output from scripts run by cron. Example:

This suppression could of course be internal to the script as well.

So the answer to your question is that you won't necessarily see any log entries from a cron script, even if it encounters an error.

One danger is that a script writer has done something like this:

This is very bad practice, because it might remove files that haven't been successfully copied, which "mv" won't do. I mention this because according to your account, the files are disappearing without being copied, and this is one of the few ways this can happen.

On a modern Linux sysem, cron scripts can be located in /etc/cron.d, /etc/cron.hourly, /etc/cron.daily, /etc/cron.weekly, and /etc/cron.monthly. Must likely the offending script is located either in /etc/cron.d or /etc/cron.hourly.

But it is possible that a daemon process is erasing the files -- it doesn't have to be a cron job. Example:

I looked in my crontab and the script or the mv command in the script aren't piped to nothing.

also, maybe i misspoke earlier, the files are getting deleted by the mv (I'm assuming), but its just when a certain user puts files in the folder that the files don't get deleted, so they keep getting scp'd over and over, creating duplicate copies.

It would make things a lot easier if you posted the script.

You mean "mv" successfully copies the files but then cannot delete them? This problem would be solved if the cron job were run with root authority. Modern cron jobs accept a user name along with the time schedule. If more than one user is using the target directory, the obvious solution is to run the cron job as root. It's also somewhat dangerous.

A side effect of the situation you describe is that if run under user authority, "mv" can copy files it is allowed to read, but the destination copies may have different ownership. This doesn't happen when the copy is performed by root.

One more thing. This business of moving and deleting files on a cron schedule is very bad practice. A user might be editing a file on either the source or destination and the file might simply disappear, or have its contents replaced instantly and without warning.

Very bad system policy.

scp -r /data1/send2joe/* user@10.11.12.13:/joe/
mv /data1/send2joe/* /data1/sent2joe/


the sent2joe folder reference in the mv command does not exist, so i'm assuming this is what's deleting the file.

actually the scp successfully copies the file, then i'm assuming the mv is what's deleting them. see my last post with the 2 commands the script runs.

the files end up in the joe folder on the other server, and majority of the time get deleted from the send2joe folder. I'm going to have the user who has problems test it out today so i can look at the file when he puts it in there. maybe he's putting a read only file in there so the mv command can't delete it (if the mv command above is even what's doing the deleting?)

Do you really need to keep track of what has/hasn't been sent? If you are only doing that part to limit what you are sending/making the script easier to write, you may want to consider rsync instead:

This will keep all the files in the "send2joe" folder however, rsync will keep track of what needs to be transferred (provided Joe leaves the files you've already sent in his /joe folder.

Just a thought,

Forrest

Just a note regarding the job checking/debugging: you can edit the cron job putting an echo in front of the mv command and redirecting the output to a file. In this way you can find out what actually the shell tries to run. Better redirect both the standard output and the standard error of the job, as suggested in a previous post:

colucix, I thought the same thing at first, but on closer examination, I saw it was send2joe and sent2joe. Good call on the log though.

Forrest

The joe folder actually is a watch folder, so once the file gets there it gets imported into another system them deleted. So truly all I need to do is 1) get the file to the joe folder on the other server then 2) delete it from the send2joe folder so it doesn't keep getting put in the joe folder and reimported over and over into the other system.

yeah, its kinda confusing with the names being so close

I saw that immediately after submitting my replay and I edited my post accordingly. You've been too fast! ;)