Bug 317714

Summary:	Consider working on NFS shares a legitimate use case (even for the targeted home environment)
Product:	[Applications] digikam	Reporter:	Holger Steinhaus <hsteinhaus>
Component:	Database-Media	Assignee:	Digikam Developers <digikam-bugs-null>
Status:	RESOLVED UPSTREAM
Severity:	wishlist	CC:	caulier.gilles, rdieter
Priority:	NOR
Version:	3.1.0
Target Milestone:	---
Platform:	Other
OS:	Linux
Latest Commit:		Version Fixed In:	7.5.0

Description Holger Steinhaus 2013-04-02 08:21:30 UTC

The first-run assistant advises not to store the metadata db on a network share. This is a very dangerous advice in environments, where all user data is normally kept on network shares and local drives are not subject to backup (like in my home environment employing a central NAS device).

Reproducible: Always

Steps to Reproduce:
n/a

Comment 1 Marcel Wiesweg 2013-04-02 19:32:22 UTC

This is not something in our scope to fix for SQLite,
Please read http://www.sqlite.org/atomiccommit.html section 9.1 for further information.
Of course, MySQL will not be affected.

Comment 2 Rex Dieter 2013-04-04 16:16:08 UTC

This?

"We have received reports of implementations of both Windows network filesystems and NFS in which locking was subtly broken. We can not verify these reports, but as locking is difficult to get right on a network filesystem we have no reason to doubt them. You are advised to avoid using SQLite on a network filesystem in the first place, since performance will be slow. But if you must use a network filesystem to store SQLite database files, consider using a secondary locking mechanism to prevent simultaneous writes to the same database even if the native filesystem locking mechanism malfunctions."

doesn't exactly say it can't work, just that it's unreliable in some nfs implementations.  am I missing something?

Comment 3 Marcel Wiesweg 2013-04-04 20:12:29 UTC

Yes, it's possible that it works, but I dont know really and cannot recommend.  I believe the message was much more strict some years ago.