DFS-R Ate My Files Again

We have a file share set up with DFS-R providing replication from one server
to another. The home server is running Windows Storage Server 2003 R2 and
the remote server is running Windows Server 2003 R2 Enterprise Edition.



The other day, I noticed that almost the entire directory containing files
that I had been working on the previous day were gone. I checked the event
log on the remote server and noticed DFS-R entries stating that the files
had been moved to the conflict and deleted folder shortly after I had left
the office. Some files were lost because the size of the directory was
larger than the 660MB quota.



Now, I don't understand why this happened. My understanding is that if a
file is modified on two servers, DFS-R will move one copy to the Conflict
and Deleted folder and the then replicate the winner. This is not what
happened. My files were removed from the home server without any events
being added to the event log and moved to Conflict and Deleted on the remote
server leaving me with nothing in the original location on both servers.



This is the second time something like this has happened this year. We do
keep backups, so it was not as disastrous as it could have been. How can I
trust DFS-R when it just randomly decided to delete files like this?

On Wed, 9 Dec 2009 11:24:03 -0500, "Marc K" <> wrote:

>We have a file share set up with DFS-R providing replication from one server
>to another. The home server is running Windows Storage Server 2003 R2 and
>the remote server is running Windows Server 2003 R2 Enterprise Edition.
>
>
>
>The other day, I noticed that almost the entire directory containing files
>that I had been working on the previous day were gone. I checked the event
>log on the remote server and noticed DFS-R entries stating that the files
>had been moved to the conflict and deleted folder shortly after I had left
>the office. Some files were lost because the size of the directory was
>larger than the 660MB quota.

DFSR does not sit happily with quotas. This is because there are some files no
replicated link .tmp files. These count towards the quota so the replicated copy
will have all the file except the .tmp files. It will therefore have free space
to store new files. However the master copy (to call it something) may still
have the .tmp file and be over quota. Hence replication fails.

>
>
>
>Now, I don't understand why this happened. My understanding is that if a
>file is modified on two servers, DFS-R will move one copy to the Conflict
>and Deleted folder and the then replicate the winner. This is not what
>happened. My files were removed from the home server without any events
>being added to the event log and moved to Conflict and Deleted on the remote
>server leaving me with nothing in the original location on both servers.
>
>
>
>This is the second time something like this has happened this year. We do
>keep backups, so it was not as disastrous as it could have been. How can I
>trust DFS-R when it just randomly decided to delete files like this?
>
--
Dave Mills
There are 10 types of people, those that understand binary and those that don't.

Dave,

Perhaps I mispsoke when I mentioned the 660MB quota. What I meant was that
the area allocated for "Conflict and Deleted" is set to a maximum of 660MB.
I myself do not have a quota that would have intereferred with the
replication process.

"DaveMills" <> wrote in message
news:...
> On Wed, 9 Dec 2009 11:24:03 -0500, "Marc K" <> wrote:
>
>>We have a file share set up with DFS-R providing replication from one
>>server
>>to another. The home server is running Windows Storage Server 2003 R2 and
>>the remote server is running Windows Server 2003 R2 Enterprise Edition.
>>
>>
>>
>>The other day, I noticed that almost the entire directory containing files
>>that I had been working on the previous day were gone. I checked the
>>event
>>log on the remote server and noticed DFS-R entries stating that the files
>>had been moved to the conflict and deleted folder shortly after I had left
>>the office. Some files were lost because the size of the directory was
>>larger than the 660MB quota.
>
> DFSR does not sit happily with quotas. This is because there are some
> files no
> replicated link .tmp files. These count towards the quota so the
> replicated copy
> will have all the file except the .tmp files. It will therefore have free
> space
> to store new files. However the master copy (to call it something) may
> still
> have the .tmp file and be over quota. Hence replication fails.
>
>>
>>
>>
>>Now, I don't understand why this happened. My understanding is that if a
>>file is modified on two servers, DFS-R will move one copy to the Conflict
>>and Deleted folder and the then replicate the winner. This is not what
>>happened. My files were removed from the home server without any events
>>being added to the event log and moved to Conflict and Deleted on the
>>remote
>>server leaving me with nothing in the original location on both servers.
>>
>>
>>
>>This is the second time something like this has happened this year. We do
>>keep backups, so it was not as disastrous as it could have been. How can
>>I
>>trust DFS-R when it just randomly decided to delete files like this?
>>
> --
> Dave Mills
> There are 10 types of people, those that understand binary and those that
> don't.