<html><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"></head><body><div>Looking at the latest OP's report it is more likely to be a bug in the Windows version of digikam.</div><div><br></div><div>As it works in the open source world, if you are not able to contribute the patch the best you can do is: first, stay calm, second, let the developers know (create a detailed bug report), third, remain calm and hope they have resources to fix your bug quickly. </div><div><br></div><div><br></div><div id="composer_signature"><div style="font-size:85%;color:#575757" dir="auto">Sent from my Samsung Galaxy smartphone.</div></div><div><br></div><div style="font-size:100%;color:#000000"><!-- originalMessage --><div>-------- Original message --------</div><div>From: Karl Günter Wünsch <kgw@mineralien-verkauf.de> </div><div>Date: 2018-01-30 11:32 AM (GMT-07:00) </div><div>To: digikam-users@kde.org </div><div>Subject: Re: All albums are removed if there is a network disconnection </div><div><br></div></div>On 30.01.18 18:11, Remco Viëtor wrote:<br>> But a local file *cannot* be "unavailable just for a short moment",<br>And here I beg to differ. What if I move the files to another mounted <br>drive? Still available but no longer in the place they were before. And <br>IIRC some information aren't stored in the sidecar files but rather in <br>the almost completely inaccessible (and ignored by most backup solutions <br>as well as many tools implementing file system operations) extended <br>attributes as the semantic desktop mandates, it's a pain to try and keep <br>those information with the original files if at all possible (the <br>networked drives don't support extended attributes and neither does the <br>NTFS driver (even though that concept is available there too)...<br><br>That mindset you just expressed has driven me away from digikam (after I <br>ran into similar issues years ago - I honestly thought they had been <br>addressed) and into the arms of the subscription of a commercial DAM <br>(along with a switch to first Windows and then after a while to MacOS) - <br>because they (unlike digikam) have embraced the concept that any <br>information in the DAM should persist until such a time when the user <br>actively chooses to remove it. There, even if I remove a file, move it <br>to another drive, move it to a NAS or anything else - yes it will lose <br>original file but it will show me that that connection has been broken <br>and I can go ahead and reestablish it - I will not lose any information <br>stored in the database.<br><br>Why can't digikam do the same thing? If the file goes missing, amend the <br>still existing preview with an icon telling the user that the original <br>has vanished. If he then wants to do something with the original prompt <br>him with the file dialog so that he can locate the original and thus <br>regain access to it. If a whole folder has gone missing (by for example <br>renaming to reflect the location) then locating one file would <br>automatically reestablish database connection for the rest. That way <br>digikam would be much more robust, it just doesn't bode well if the <br>database information are still lost so easily...<br></body></html>