problem with tar

UNIX for Advanced & Expert Users
1

First of all I have already asked about this in the scripts/perl forum but the advice I got did not do the trick.

A script I have to use unzips some xxx.tar.gz files and then tries to tar -xvf them. on the tar -xvf I get the following:-

tar: code/sql: Cannot utime: Operation not permitted
tar: code/scripts: Cannot utime: Operation not permitted
tar: code/maestro: Cannot utime: Operation not permitted
tar: code: Cannot utime: Operation not permitted

It was suggested to me that the OS was not happy with the tar file (maybe created under another flavour of UNIX). Accordingly, I have now got the tar files created under the same unix flavour

Linux <hostname> 2.6.9-55.ELsmp #1 SMP Fri Apr 20 17:03:35 EDT 2007 i686 i686 i386 GNU/Linux

Does anyone have any ideas?

regards

2

It looks like an issue with permissions? Does the directory and the files that you untar belong to the user that invokes the script? Try to use the option --no-overwrite-dir.

Regards,
-Oktawik.

3

I also feel that it seems to be a permission issue

Regards

4

Many thanks to both for the response.

I will investigate this

cheers

5

Hello again,

this is beginning to drive me nuts.

I have opened up the permissions on the target dir (definied via a -C switch in the tar command) and it still moans about utime (tar: code: Cannot utime: Operation not permitted).

Can anyone give me an idea about what permissions are expected for utime to be happy?

BR

Alastair

6

Permission to give it a beer.

7

I just experienced this issue.

By adding an m to my options I got past this.

This only occurred for me when overwriting files by extracting the tarball. The -m (or m) option tells tar not to 'touch' the files and there by not calling utime to update the timestamp.

hth

8

To invoke utime() you must:
1) own the file or be root
2) have write permission on the file or be root

My guess is that your archive has files owned by you but read only.

9

Yes, but the funny thing is, I either owned every file or had full rights to it as it was in my primary group.

It is some weird thing with the server, but I have no access to that level of it. If I did it wouldn't be RHEL. :stuck_out_tongue:

10

What kind of filesystem are you extracting it on to?

11

There is no such thing as "full rights" to a file you do not own unless you are root. Invoking utime() is not reading, nor writing, nor executing a file. You must own the file or you do not have the right to invoke utime(). This is a posix mandated restriction.

Other things you can't do to a file you don't own even if the permissions are 777: chmod, chgrp, and chown. Many OS's won't allow chown even by the non-root owner, but allowing a non-root non-owner to chown a file is a posix violation. All of these things affect the inode, not the data. You can have full right to the data in a file you don't own, but not to the metadata that describes the file. The metadata belongs only to the file owner.

12

Why dont you just try to run script as root under empty directory and if it works, so we can say problem is of permissions.

  • nilesh
13

I do not have that level of access. This is a server setup by our network department for us to develop on.

14

It is an ext3 partition that is apparently on a SAN.

15

Yes, I understand this. When I said full-rights, I only meant rwx. Interestingly enough, tar extraction will chown the file to the extractor if the extractor has write rights to the file to affect a replace.

I was merely citing a work-around to the initial poster.