> What we're thinking of doing is pushing the PENDING_BYTE from the first > byte past the 1GB boundary to somewhere deep in the 64-bit range (such > as perhaps the 1TB boundary). We would have to update many lock and > unlock calls in os_win.c to do so, mainly adding a high-order 32-bit > number to the lock offset. Is anyone aware of any issues with doing so, > either with SQLite or Windows? Would we have to change anything else in > SQLite other than in os_win.c? We don't use anything older than Windows > 2000, so older systems shouldn't be a concern for us.
Might it be simpler to extract the underlying file handle from the sqlite3 structure? Once you have this handle, you could manually perform a file copy, reading & writing a block at a time. Since it's the same handle that was granted the lock, you should have no access restrictions. Though I haven't tried it, I would hope that the block-by-block copy would have similar performance to the O/S CopyFile call. Granted, there may not be any "supported" way to extract the file handle from the sqlite3 struct. However, it has to be at least as easy as updating the code to move the PENDING_BYTE location, as you propose above. Plus, it avoids the compatibility issues mentioned by DRH. ~Eric _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
