Hi there, We are performing backups of the SQLite DB file by opening an IMMEDIATE transaction and then copying the file. (cf. <http://www.mail-archive.com/sqlite-users@sqlite.org/msg19265.html>, <http://www.mail-archive.com/sqlite-users@sqlite.org/msg19311.html>)
On Windows we use CopyFileA (within the same process that opened the DB transaction) to perform the copy. We've noticed that copies fail on Windows for databases larger than 1 GB in size. We suspect this is due to SQLite locking bytes around the 1GB offset whenever a transaction is opened on Windows. This may be due to the fact that the locking file handle gets exclusive access; other file handles opened by the same process also cannot access the same locked region. (cf. <http://msdn.microsoft.com/en-us/library/aa365202(VS.85).aspx>) 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. Thanks, Arun _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
