Unusual file permission resulting occasionally when cp'ing a file.

[Randy Brown_1]

We are occasionally seeing some unusual behavior when copying a file from inside a script. Without going into the details of the script, at one point it copies a file to a temporary location and then moves the file to it's final destination so that the rest of the script does not act on a partially copied file. Occasionally, when the file is copied, the file will have no permissions set. e.g., ----------. At this point the script is dead in the water and the user has to get someone with root privileges to remove the file with no permissions which in inconvenient for the user.

It seems to me that the cp command, for whatever reason, just doesn't finish and therefore permissions are never applied to the file.

The machine is a J9000 running HP-UX 10.20.

If more information is needed, I will gladly provide it. I'm inclined to tell the user to just deal with it since the machine is VERY old and will, most likely, be taken out of service within the year.

Any information/thoughts as to why this may be occurring are greatly appreciated.

Thanks!

Randy

[RAC_1]

When file is being copied, looks like it is being used by some process and as result cp can not copy it fully. Revisit your script.

Are you moving file or copying it??

fuser -u /dir/your_file

Anil

[A. Clay Stephenson · Accepted solution]

You've hit the nail on the head. The copy is
failing and the mode is left at 000. The chmod is not done until the copy operation finished; however, unless the sticky bit is set on the directory; if the user has write permission on the directory, he can remove the file. Permissions on the file have nothing to do with the ability to remove the file. It would seem rather easy to add a few extra if's to the script to fix this. I suspect the cp command is receiving a signal and aborting or the filesystem is running out of space.

[Randy Brown_1]

The reason the script is written the way it is - cp the file to a temp location and then move it - is to avoid a process acting on the file before the copy is complete.

This has only been seen on the HP machine. The same script is being run in a linux environment and has never seen this problem.

The user has write perms to that directory and there is no sticky bit on the directory, but the user still cannot remove the file.

This script works as expected 99% of the time. This is only an occasional occurrence, but it is a pain when it occurs.

Thank you for your prompt responses. This Forum is great!

Randy

[A. Clay Stephenson]

There is something you aren't telling me, like is NFS involved in this? If these are local files then anybody with directory write permission can remove the file.

Do this as a test:

Create a file as root (or another user) in a directory writable by you as a regular user.
echo "Test" > myfile
chmod 000 myfile
ls -l myfile to make sure it is ----------.
Now as yourself, rm -f myfile.

[Randy Brown_1]

Yes, this is occurring on an nfs mounted filesystem. However, I just performed your test successfully on both an nfs mounted file system and a local file system. That would make sense though, as the permissions to delete a file come from the directory level, correct?

Now I'm wondering if I'm getting accurate information from the user. What are the odds of that? ;-)

I'll have them notify me the next time it happens and see what the circumstances are first hand. I think something's being lost somewhere.

Thanks again for the response!

Randy