file changes after cp

[Peter Heinemann]

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.

[Shannon Petry]

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

[Jdamian]

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

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

[Hai Nguyen_1]

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

[Steven E. Protter]

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

[Peter Heinemann]

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.

[Michael Steele_2]

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 "-".

[Jean-Louis Phelix]

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.

[Frank Slootweg]

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?

[Peter Heinemann]

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.