[Box Backup-dev] COMMIT r896 - box/chris/merge/lib/raidfile

[Chris Wilson]

Hi Ben,

Regarding [http://bbdev.fluffy.co.uk/trac/changeset/896]:

On Fri, 1 Sep 2006, Ben Summers wrote:
> 
>>  Open files in binary mode (Win32)
>
> Can that go in the base classes instead? I can't think of any reason why 
> we'd want to open a file in anything other than binary mode.

Do you mean FileHandleGuard, or openfile(), or both?

>>  Disable the lock failure block when we don't have any locking 
>>  mechanism
>
> Win32 does have locks! Why not add an emulated flock() for Win32?

It seems to me that a lot of functionality in RaidFileWrite is duplicated 
from FileStream. I have to rewrite all this code to call different 
functions and work with native file handles (HANDLE) on Win32, in order to 
be able to call LockFile or LockFileEx APIs. I can't see any other way to 
lock files on Win32.

Would it make sense to merge the file-handling parts of RaidFileWrite into 
FileStream? I think this means that some extra APIs will be required in 
FileStream. Either RaidFileWrite needs to get access to FileStream's 
internal file handle (ugly but minimal) or locking must be added to 
FileStream (preferable?).

What exactly is the lock protecting against? Simultaneous writes to the 
same file by RaidFileWrite? Since the Win32 APIs require one to specify 
the byte range in the file to be locked, is it acceptable to just lock the 
first byte, to achieve mutual exclusion?

Cheers, Chris.
-- 
_ ___ __     _
  / __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer |
\ _/_/_/_//_/___/ | We are GNU-free your mind-and your software |