[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: RE: RE: Re: Problem using copyfile and movefile
From: |
John W. Eaton |
Subject: |
RE: RE: RE: Re: Problem using copyfile and movefile |
Date: |
Thu, 1 Mar 2007 13:51:37 -0500 |
On 1-Mar-2007, address@hidden wrote:
| > This more elaborated version also implements recursive copy of
| > directories. What's not handled yet is cyclic copy detection.
|
| I took a more conservative and OO-oriented approach to
| implement copy mechanism: now it's a 2-steps process, avoiding
| cyclic problems. See code in attachment (starting from my previous
| patch, this code can be copy'n'paste into file-ops.cc in place of
| the actual code from the patch).
|
| What do you think?
|
| Note that this does not support symlinks: it's harder for me to
| implement and test as there's no symlinks under Win32.
I haven't tested it, but since copying a symbolic link copies the file
that the link points to, not the link itself, I think your copy
function would work for them.
The core of your function is
for (;;)
{
nr = ::read (fd_src, buf, BUFFER_SIZE);
if (nr == 0)
{
status = 0;
break;
}
else if (nr < 0)
break;
else
{
nw = ::write (fd_dest, buf, nr);
if (nw != nr)
break;
}
}
I think you may need to handle the possibility of errno == EINTR after
the read and write, and also loop around the write (it is not an error
for write to return a value less than the total number of bytes that
it is requested to write).
All these little details are precisely what I wanted to avoid by using
the gnulib code, which has already considered them and presumably has
all the bugs worked out. Also, I don't want to be the maintainer of
this code when there is already a project that implements the
functionality and is maintained by people who probably know better
than we do how to get the details right.
jwe