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
> 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 whethe
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* f
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
http://sqlite.org:8080/cgi
> 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 wi
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 being *unable* to do tha
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 lower-l
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 a
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 a database file insid
@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 amo
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 associated WAL and whate
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?
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 Dec 2013, at 12:00am,
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 from some of
the low-level p
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
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
> 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. I
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 (1)-(
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 can move the database
> 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 po
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 journal file). Thi
> 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 journa
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 year
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 m
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 whether the flag is a reg
> 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 fil
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 further damage?
>
>
.
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. Wood wr
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.
>
> Are there other
s of 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
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.
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
32 matches
Mail list logo