Re: [sqlite] Concrete example of corruption

At 08:45 11/12/2013, you wrote: My case wasn't about messing anything up, but simply moving a document. Just like moving the canvas while the artist is painting? Or is it moving the notebook while the schoolkid writes on it? This is prone to produce dribbles or worse, in my view. I fail to

Re: [sqlite] Concrete example of corruption

> D. Richard Hipp wrote: > Please try the changes in the branch at > http://www.sqlite.org/src/info/8759a8e4d8 and > let me know if they adequately cover your concerns. I don't have enough expertise with the SQLite codebase to be able to tell for sure. You will always know better than me

Re: [sqlite] Concrete example of corruption

Richard Hipp wrote: > Please try the changes in the branch at > http://www.sqlite.org/src/info/8759a8e4d8 and let me know if they > adequately cover your concerns. Let's suppose user just did cp -b somewhere/else/db opened.db There *are* still file named opened.db, but it points to *different*

Re: [sqlite] Concrete example of corruption

Please try the changes in the branch at http://www.sqlite.org/src/info/8759a8e4d8 and let me know if they adequately cover your concerns. -- D. Richard Hipp d...@sqlite.org ___ sqlite-users mailing list sqlite-users@sqlite.org

Re: [sqlite] Concrete example of corruption

> Simon Slavin wrote: > If you can't trust your users not to > move data files out of place I was not talking about data files but regular documents (package folders). Moving regular documents has nothing to do with trust. It's a fact of everyday reality. > Stephen Chrzanowski wrote: > Even

Re: [sqlite] Concrete example of corruption

On 06 Dec 2013 at 03:31, Stephen Chrzanowski wrote: > On a personal note, I still cannot fathom why anyone would WANT to do file > management while working on an active document. Moving a document while > its being worked on contradicts everything I understand. I find

Re: [sqlite] Concrete example of corruption

Warren Young wrote: > On 12/5/2013 20:31, Stephen Chrzanowski wrote: [...] >> File handling is NOT SQLites responsibility > > I'm not sure about that. SQLite, at least at one time, was billed as a > competitor for fopen() rather than for Oracle. But fopen(3) have no locking *at all*. And

Re: [sqlite] Concrete example of corruption

On 12/5/2013 20:31, Stephen Chrzanowski wrote: @Warren> the package/sandbox idea won't work due to certain constraints the OS puts on the file. Quoting the Apple docs[1] Doug pointed to: "...you can access the document's contents using any appropriate file-system routines." I'd like to see

Re: [sqlite] Concrete example of corruption

On 6 Dec 2013, at 3:31am, Stephen Chrzanowski wrote: > It was mentioned in another thread, of this exact subject (I think this is > the third thread?) that the package/sandbox idea won't work due to certain > constraints the OS puts on the file. On one hand, you can't keep

Re: [sqlite] Concrete example of corruption

@Warren> It was mentioned in another thread, of this exact subject (I think this is the third thread?) that the package/sandbox idea won't work due to certain constraints the OS puts on the file. I don't recall what the reason was, exactly, as I've never used a Mac for any kind of considerable

Re: [sqlite] Concrete example of corruption

On Dec 5, 2013, at 8:55 PM, Warren Young wrote: > On 12/5/2013 17:00, Scott Robison wrote: >> Might there be a way to implement a custom VFS for Mac to deal with this? > > Wouldn't it be a lot simpler to just put the DB file into a Mac package (i.e. > directory) so the

Re: [sqlite] Concrete example of corruption

On 12/5/2013 17:00, Scott Robison wrote: Might there be a way to implement a custom VFS for Mac to deal with this? Wouldn't it be a lot simpler to just put the DB file into a Mac package (i.e. directory) so the associated WAL and whatever other files get created in the package, too?

Re: [sqlite] Concrete example of corruption

I wasn't trying to suggest it be added to an official VFS shipped with SQLite. Just pondering if there might be a way for people who want or need such functionality to integrate it cleanly via the VFS mechanism. On Thu, Dec 5, 2013 at 5:24 PM, Simon Slavin wrote: > > On 6

Re: [sqlite] Concrete example of corruption

On 6 Dec 2013, at 12:00am, Scott Robison wrote: > Might there be a way to implement a custom VFS for Mac to deal with this? One problem is that to be able to call fsevents you have to link in a huge amount of the standard Mac support some of which isn't accessible

Re: [sqlite] Concrete example of corruption

Might there be a way to implement a custom VFS for Mac to deal with this? On Thu, Dec 5, 2013 at 3:55 PM, William Garrison <1billgarri...@gmail.com>wrote: > On Thursday, December 5, 2013, L. Wood wrote: > > > A fact of reality: Documents can be moved by the program's users. > > > > The database

Re: [sqlite] Concrete example of corruption

On Thursday, December 5, 2013, L. Wood wrote: > A fact of reality: Documents can be moved by the program's users. > > The database should not be corruptible in this case. At most, I should get > errors from SQLite that I can handle gracefully. > > This is a normal thing. We are simply driving our

Re: [sqlite] Concrete example of corruption

> Simon wrote: > > Doesn't help. Because the corruption can happen > if the journal file is moved after the app has crashed. > And if the app has crashed it doesn't have any of the files > open and can't monitor them being moved. D. Richard Hipp's scenario was not about "our" program crashing.

Re: [sqlite] Concrete example of corruption

On 2013/12/05 16:40, L. Wood wrote: Could you be clear on what issue it is that you want solved, and how your proposal solves it any better than what is currently being done ? L. Wood: We are trying to find ways to avoid the corruption problem that D. Richard Hipp outlined. See his steps

Re: [sqlite] Concrete example of corruption

On 5 Dec 2013, at 2:40pm, L. Wood wrote: > We are trying to find ways to avoid the corruption problem that D. Richard > Hipp outlined. See his steps (1)-(5) in a previous post. Okay. Sorry, but this is not possible using a client/client DBMS and a setup where your users

Re: [sqlite] Concrete example of corruption

> Simon Slavin wrote: > Could you be clear on what issue it is that you want > solved, and how your proposal solves it any better than > what is currently being done ? We are trying to find ways to avoid the corruption problem that D. Richard Hipp outlined. See his steps (1)-(5) in a previous

Re: [sqlite] Concrete example of corruption

On 3 Dec 2013, at 4:09pm, L. Wood wrote: > Here is a cross-platform idea: > > Add a new mode where the journal is opened once for reading/writing when > first needed and left open until the database is closed (as opposed to the > default way, to repeatedly create/delete the

Re: [sqlite] Concrete example of corruption

> Metadata is not cross-platform. That would only work on a mac. Here is a cross-platform idea: Add a new mode where the journal is opened once for reading/writing when first needed and left open until the database is closed (as opposed to the default way, to repeatedly create/delete the

Re: [sqlite] Concrete example of corruption

On 01/12/13 06:10, L. Wood wrote: > D. Richard Hipp, are there any plans to make this more robust in the > future, so reading/writing a corrupt database (with no -journal file > available) will return an *error* instead of causing further damage? There has been a ticket languishing for many

Re: [sqlite] Concrete example of corruption

Hi L, This seems to be a somewhat classic case of "If your only tool is a hammer, every job resembles a nail...". Not only is Meta-data only a Mac thing, the ideal is non-reachable. What I mean is: There is an infinite number of things that will kill a system, (any system), we single out the

Re: [sqlite] Concrete example of corruption

On Sun, Dec 1, 2013 at 6:35 PM, L. Wood wrote: > > Not possible. Doing any writes to the database file (such as to set a > > flag) requires a journal file, otherwise a power loss in the middle of > the > > write can cause database corruption. > > It doesn't matter at all

Re: [sqlite] Concrete example of corruption

> Not possible. Doing any writes to the database file (such as to set a > flag) requires a journal file, otherwise a power loss in the middle of the > write can cause database corruption. It doesn't matter at all whether the flag is a regular write to the actual file or merely metadata on the

Re: [sqlite] Concrete example of corruption

On Sun, Dec 1, 2013 at 9:10 AM, L. Wood wrote: > This makes sense now, thanks. > > D. Richard Hipp, are there any plans to make this more robust in the > future, so reading/writing a corrupt database (with no -journal file > available) will return an *error* instead of causing

Re: [sqlite] Concrete example of corruption

. What do you think? Possible? Impossible? > From: d...@sqlite.org > Date: Sat, 30 Nov 2013 17:30:01 -0500 > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Concrete example of corruption > > On Sat, Nov 30, 2013 at 5:15 PM, L. W

Re: [sqlite] Concrete example of corruption

On Sat, Nov 30, 2013 at 5:15 PM, L. Wood wrote: > Thanks, that makes sense. > > But I can pretty much rule this case out. In my case, it's highly unlikely > that the folder would be moved during the brief instant between _open() and > the actual opening of the "-journal" file.

Re: [sqlite] Concrete example of corruption

corruption? > Date: Sat, 30 Nov 2013 22:26:21 +0100 > From: clem...@ladisch.de > To: sqlite-users@sqlite.org > Subject: Re: [sqlite] Concrete example of corruption > > L. Wood wrote: >> /Users/lwood/Desktop/folder/db.sqlite >> >> Suppose I can only

Re: [sqlite] Concrete example of corruption

L. Wood wrote: > /Users/lwood/Desktop/folder/db.sqlite > > Suppose I can only move/rename the *folder*. Suppose I never mess with the > folder's contents. > > Can you name me a concrete example of corruption that could occur? 1. Open "/Users/lwood/Desktop/folder/db.sqlite". 2. Rename the folder.

[sqlite] Concrete example of corruption

Let me put it this way: Suppose I have my main database file *in a folder*: /Users/lwood/Desktop/folder/db.sqlite Suppose I can only move/rename the *folder*. Suppose I never mess with the folder's contents. Can you name me a concrete example of corruption that could occur? It seems that all