On Wednesday 27 October 2010 12:22:31 am u-codalist-f7q1_at_aetey.se wrote:
> My impression from a conversation with Phil some time ago was that 
> it would not be too hard to make Coda work there.

Currently, Coda for Windows works well with cygwin-1.7 tree.  This was
the first major need to get Coda on Vista and Windows 7.   The second
part is the kernel module.  We are currently using a rather old version
of OSR's FSDK, a file system development kit.   Newer versions put
restrictions on certain operation modes used by the Coda kernel module.
Specifically, *many* windows programs open files for R/W even though
they don't intend to write.  This was causing essentially every opened file to
be sent back to the server even there were no changes.   To deal with that,
the Coda kernel module just opened files as read-only until a write was
actually performed and then it would re-open the file for R/W.   This 
open for read and then reopen for write if needed is now restricted and 
causes a blue screen in the recent versions of FSDK.

Here is what I'd do to fix this if I had the time:

   Change the kernel module to open for R/W but keep track if any
   writes were performed.

   Change the close() upcall to venus to include whether the file
   was actually written or not so venus could know if there were
   and changes to the file and not send back unchanged files to
   the server.

Jan has suggested changing venus to check and see if a file that
was closed had changed by storing a hash of each file and recomputing
that hash at close time.   If the hashes match, then the file is
unchanged and not sent back to the server.   This would allow unchanged
files to not be send on any use of venus, not just on Windows.

Neither change has been made to venus and one of the two changes is
required to be able to start the change to the Coda Kernel Module for
Windows.

My estimate would this would require around 100 hours of work.

--Phil

-- 
Phil Nelson,  http://pcnelson.net
http://www.goallpower.com