topic Re: file changes after cp in Operating System - HP-UX

file changes after cp

Peter Heinemann — Wed, 26 Mar 2003 14:23:42 GMT

After copying a large file, the internal structure seems to be dramatically different. Note what happens with wc.

Original file:
# ll prestg_extra_08012002.dat
-rw-r----- 1 orionadm orion 2692865136 Mar 13 09:55 prestg_extra_08012002.dat
# wc -c prestg_extra_08012002.dat
2692865136 prestg_extra_08012002.dat

# wc -m prestg_extra_08012002.dat
2692865136 prestg_extra_08012002.dat

# wc -l prestg_extra_08012002.dat
3634096 prestg_extra_08012002.dat

copy:

# cp prestg_extra_08012002.dat tmp.dat

# ll tmp.dat
-rw-r----- 1 root sys 2692865136 Mar 26 09:01 tmp.dat

# wc -l tmp.dat
88 tmp.dat

# wc -c tmp.dat
65536 tmp.dat

# wc -m tmp.dat
65536 tmp.dat

Any ideas what's happening, and how to resolve it? Is this standard behavior for cp?
Is it the nature of the file itself?

Thanks.

Re: file changes after cp

Shannon Petry — Wed, 26 Mar 2003 14:28:13 GMT

It looks like your copying a database which is not shut down, so it can not be correctly copied, or... your running out of file space in the location your copying too.

You can not copy a dabase with it open as it will error on the open blocks.

Now, I have seen minor changes in file sizes when being copied from large block file systems to small blocks. I.E. In FEA I use 8K blocks for scratch, most of the time these files reduce in size when being copied to a 1/2K block file system.

But.. the binary contents will not change unless there is one of the 2 issues I mentioned going on.

Regards,
Shannon

Re: file changes after cp

Jdamian — Wed, 26 Mar 2003 14:28:30 GMT

Did you notice that your file is bigger than 2 GB ?

Does the destination File System support files bigger than 2 GB ?

Re: file changes after cp

Hai Nguyen_1 — Wed, 26 Mar 2003 14:30:25 GMT

Strange. The copied file should have been identical. Otherwise, the copy process was somehow imperfect. You may want to copy again. I noticed that your original is very big; make sure you have enough space to copy.

Another way to verify the integrity of the file is to use "cksum". For example:

# cksum file.original
# cksum file.copied

You should obtain the same outputs if the original and the copy are identical.

Hai

Re: file changes after cp

Steven E. Protter — Wed, 26 Mar 2003 14:32:30 GMT

Possible causes:

Copying an open database(mentioned above)

Copying a 2.6 Gig file to a filesystem that is not enabled with largefiles. To rebuild newfs -F vxfs -o largefiles In HP-Ux below 11.11, you'll need a largefiles entry in the /etc/fstab file which automounts filesystems at system start.

SEP

Re: file changes after cp

Peter Heinemann — Wed, 26 Mar 2003 14:34:21 GMT

General reply:

1) It's not a database. It's a flat file. It wasn't open by any process when copied.

2) note the original post. I made a copy in the same directory. If largefiles wasn't enabled, the source file couldn't be that large.

Re: file changes after cp

Michael Steele_2 — Wed, 26 Mar 2003 14:44:02 GMT

I've never seen where "...cp -p -r..." for large files over 2 GB has failed, but HP has warned about it and recommends fbackup piped to frecover instead. You can use cksum on the original file and the copy afterwards. cksum will test the integrity of the fbackup.

cd /destination
fbackup -i /tmp/source -f - | frecover -x -X -f -

Note the dashes "-".

Re: file changes after cp

Jean-Louis Phelix — Wed, 26 Mar 2003 15:02:40 GMT

Hi,

Never seen that ... Perhaps I would check the filesystem using fsck and try again. You should also rather use cksum to check files, but wc should also work, at least -c option.

Regards.

Re: file changes after cp

Frank Slootweg — Fri, 28 Mar 2003 09:23:53 GMT

As mentioned, do a cksum(1) on the original and copy and compare/post the results.

Also do a du(1) on the original and copy and compare/post the results.

You mentioned what the file is not (a database file), but not what it is. What kind of file/data is it?

Re: file changes after cp

Peter Heinemann — Fri, 28 Mar 2003 13:33:21 GMT

thanks for replies. Problem is most likely on the SAN side; I moved the file system to a new set of disks and the problem cleared.