Hello,
fileutils version: 4.1
cc: gcc
os: solaris 7
I made a copy of my files with the '-a -v -u' flags. I then re-ran cp
with the same flags on the same files (none of which had changed and it
updated a significant proportion of them.
As a simple example:
# ls -l .tcshrc*
-rw-r--r-- 1 stewar
Hi GNU folks,
I've found a difference in behavior between the cp in fileutils-4.0x and
the cp in fileutils-4.0.35. I'm not sure if the new behavior is a bug,
but I do know that I prefer the old behavior. :-) Here's the scoop:
Using fileutils-4.0x:
[root@h20:/disk2] mkdir a
[root@h20:/disk2
I tried this on another system, which was ostensibly running the same
version of fileutils, and it worked "normally". Perhaps this odd behavior
is caused in some way by the fact that I'm running Debian's unstable
distribution. I will investigate further along these lines.
Sorry for any confusion
me@here:~$ touch quux
me@here:~$ mkdir foo
me@here:~$ ln -s ../quux foo/quux
me@here:~$ ls -l foo
total 0
lrwxrwxrwx1 me us 7 Dec 11 07:59 quux -> ../quux
me@here:~$ cp -r foo bar
me@here:~$ ls -l bar
total 0
lrwxrwxrwx1 me us 7 Dec 11 07:59 quux -> ..
We are copying from ext2 to nfs (ext2) file system. The version of cp
that we have here is 4.0p. I was not using --sparse=always. I will try
it and see the results.
The way oracle allocates data files is such that they are bound to have
a lot of blocks of 0 bytes. We have oracle block size of 8 k
Shamsher Sandhu <[EMAIL PROTECTED]> wrote:
| I am using Oracle here on Redhat 6.2 load. We are copying oracle
| databfiles for backup using cp command. The copy is happening when oracle
| is down. The copy is being done across nfs. The problem is that sometimes
| the copied file is of different si
I am using Oracle here on Redhat 6.2 load. We are copying oracle databfiles for backup
using cp command. The copy is happening when oracle is down. The copy is being done
across nfs. The problem is that sometimes the copied file is of different size than
the original one. The difference can ran
Thanks for the report.
That's fixed in the latest test release.
ftp://alpha.gnu.org/gnu/fetish/
Brian Thomas <[EMAIL PROTECTED]> writes:
| Please review the following truss output. The bug (If it is indeed a bug)
| seems to crop up with doing cp with the -Rf options, when copying files
| that a
Please review the following truss output. The bug (If it is indeed a bug)
seems to crop up with doing cp with the -Rf options, when copying files
that are the same atop one another. Although cp correctly identifies them
as identical, after that it unlinks the 'target' in preparation for a copy
tha
