Files - DFS Share Not Replicating or Not Saving Properly

here is a blog post on Offline Files and DFS Shares
http://blogs.technet.com/b/netro/archive/2011/01/24/using-offline-files-on-dfs-shares-all-shares-are-going-offline.aspx

which could be causing conflicting files if the share is using the Offline Files feature

Regarding your first question, yes if your DFS targets are on different servers and are being replicated, this can certainly cause conflicts. DFS does *not* provide any locking mechanism so you have to plan for this when implementing DFS. DFS-R is great, for example, to get files from a remote site to a central backup site (where users aren't editing files) or to get read-only files from a central site to a remote site (for software deployment, for example) but is NOT well suited if there is a chance where multiple users will open the same file at the same time. Which is what it sounds like you are running into. This is an inherent limitation of DFS.

Regarding your second question, none of the features you name will help with your situation nor will they improve replication. They tackle different problems and certainly can be deployed with DFS. The dynamic of how they work doesn't change that much. But again, they aren't designed to solve your problem. They are intended (individually and potentially together) to solve other pain points in different topologies (mobile workers, small offices without a dedicated DFS server, unreliable WAN links, etc.)

I don't think multiple users editing files is the main problem, It is more that other users are not seeing other files which have been created or the most up-2-date file. That is why I thought those other features I was reading may help to improve efficiency over the network.  Last question, any suggestion of a non-dfs solution?

I appreciate your time and help.

You need to recheck the topology you have. Your DFS replication group might have work fine till now but now an unanticipated use is what causes your difficulty.
First thing to check is whether the user has access to the files they could not access the following day, that will point to the user having marked the DFS shared data as offline access as was mentioned earlier.  Viewing a listing on a folder, there is an option that will indicate that this folder is an offline reflection of the data.
Comparing the DFS target being accessed by this user will help clearup the matter further since you can then access the share and see whether the files are there and if not check the DFS/DFS replication event log to see whether there are issues there.

Others also covered the conflict detection/events.

what is the replication topology, make sure the member servers of the replication have 2 functioning connection to match the topology. I.e. If hub and spoke you have each server with an outgoing and receiving feed and both are marked as functional. One has the option to mark a connection though present as disabled preventing data from flowing through it.

Thanks Arnold. I will re view these.