Bug 189168

Summary: You do not have write access to your home directory base path
Product: [Applications] digikam Reporter: tps
Component: Setup-CollectionsAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: normal CC: caulier.gilles, Ch.Ehrlicher, marcel.wiesweg, meldavid, ps_ml
Priority: NOR    
Version: 0.10.0   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In: 1.0.0
Sentry Crash Report:
Attachments: Patch with temporary file as check for read only

Description tps 2009-04-09 01:20:50 UTC
Version:            (using KDE 4.2.2)
Compiler:          MSVC 
OS:                MS Windows
Installed from:    MS Windows

After installing digikam exausts "You do not have write access to your home directory base path". Only a button "OK" is shown. Hitting this button an other dialog appears asking you to change the given path.

Changing the path does not help in any way. Same error message over and over again. Looks like there is some serious problem with checking access rights on Windows!

BTW: the error message is wrong. I *do* indeed have rights to write all parts of my home path!
Comment 1 caulier.gilles 2009-04-09 19:17:34 UTC
I confirm. It's always reproducible under XP or Vista.

Patrick, 

Code relevant is here :

http://lxr.kde.org/source/extragear/graphics/digikam/digikam/digikamfirstrun.cpp#327

Gilles
Comment 2 Christian Ehrlicher 2009-04-12 15:29:35 UTC
Should be fixed some time ago with the KUrl::path() -> KUrl::toLocalFile() - fixes.
Comment 3 tps 2009-04-12 22:14:54 UTC
In this case: i there a new build available for Windows?
Comment 4 tps 2009-04-19 19:40:00 UTC
INstaled a new build: same result. --- seems not to be fixed!
Comment 5 caulier.gilles 2009-04-19 19:54:02 UTC
Chistian,

I confirm. Both XP and Vista has the problem.

I don't understand why M$ win32 user directory is too complicated to drive.

What's the problem exactly ?

PS : like i hate M$ OS...

Gilles Caulier
Comment 6 caulier.gilles 2009-04-19 20:56:53 UTC
Ok, 

It's very nice ! My file system is FAT32.

Under win32, take file manager, go to your images location from your home directory.

For me, it's "C:\Documents and Settings\Gilles\Mes documents\Mes images"...

Look file properties of this folder : it's read only.

The question is Why ???

Under Win32, FAT32 read only attribut is dummy. it's just a flag to prevent to remove a folder to user if necessary. You can alawys wrap around this restriction.

I have not tested with NTFS instead...

tps, What's your file system exactly ?

Gilles Caulier
Comment 7 tps 2009-04-19 21:09:12 UTC
Filesystem NTFS 5.0 (Windows XP)
The user "tps" has all rights on "C:\HOME\tps\My Documents\My Pictures". He is allowed everything. Had a look at files to be created (mybe they exist). Files do not exist. Had debugging on, then looking what is going. Found: the files do not exist, stat gives back an error (code file does not exist) digiKam takes this error code and exausts the wrong error message!

If you could confirm this ...

I could try to create the files neccessary manualy, then try again --- maybe this gives some more idea what is going wrong!
Comment 8 Christian Ehrlicher 2009-04-19 21:32:01 UTC
I can confirm it with ntfs and will do some more debugging in the next days. In the meanwhile another location does work.
Comment 9 caulier.gilles 2009-04-19 23:39:21 UTC
Yes, it's work in another place, as C:/temp for ex.

But why home dir has read only flag ? I would to understand M$ logic (if there is one...)

Gilles Caulier
Comment 10 caulier.gilles 2009-04-21 21:26:08 UTC
Ok, this is the solution : 

Original post :

http://techrepublic.com.com/5208-6230-0.html?forumID=5&threadID=173729&messageID=1787054

The response :

http://techrepublic.com.com/5208-6230-0.html?forumID=5&threadID=173729&messageID=1767669

and the solution :

http://techrepublic.com.com/5208-6230-0.html?forumID=5&threadID=173729&start=0&tag=rbxccnbdisc1

Do not start an easy troll. M$ OS are really great and are used everywhere on this planet. Please respect god (-:=)))...

Gilles Caulier
Comment 11 Christian Ehrlicher 2009-04-22 06:29:36 UTC
I wolud suggest using 'My Pictures\Digikam' as directory.
Also do you think it's a godd idea to put the database into 'My Pictures' ?
Comment 12 caulier.gilles 2009-05-07 12:39:54 UTC
I love : how M$ wrap around std posix file attribut to invents new rules... I hate M$ :

http://support.microsoft.com/kb/256614

This compagny is completely dummy... 


To Christian : you can customize DB file place where you want on your HDD.
Comment 13 caulier.gilles 2009-05-11 23:07:05 UTC
Code relevant is now moved to new First Run assistant. Problem still the same :

http://lxr.kde.org/source/extragear/graphics/digikam/utilities/firstrun/collectionpage.cpp#250

http://lxr.kde.org/source/extragear/graphics/digikam/utilities/firstrun/collectionpage.cpp#315

Gilles Caulier
Comment 14 David Eriksson 2009-05-17 23:08:16 UTC
Hi,

I have looked at this and as noted above and in this note http://doc.trolltech.com/4.5/qfile.html#platform-specific-issues isWritable can't be trusted on Windows. The attached patch instead creates a temporary file to test if the directory is writable. It also fixes the same problem in SetupCollections. Is there a reason way in SetupCollections this check only renders a warning and one can go ahead and try to move the database or create a new in read-only directory, which will fail?

David
Comment 15 David Eriksson 2009-05-17 23:09:22 UTC
Created attachment 33777 [details]
Patch with temporary file as check for read only
Comment 16 caulier.gilles 2009-05-18 07:55:34 UTC
SVN commit 969357 by cgilles:

apply patch #33777 from David Eriksson
CCBUGS: 189168


 M  +17 -0     firstrun/collectionpage.cpp  
 M  +15 -3     setup/setupcollections.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=969357
Comment 17 caulier.gilles 2009-05-18 08:07:47 UTC
>Is there a reason way in SetupCollections this check only
>renders a warning and one can go ahead and try to move the database or create a
>new in read-only directory, which will fail?

David,

I'm not sure to understand your question...

Gilles Caulier
Comment 18 David Eriksson 2009-05-18 12:06:13 UTC
Gilles,

If I choose a read-only directory in the First Run assistant I can not go on with the setup. If I in the SetupCollections chooses a read-only directory I get a warning. Then after the warning I can still press Ok. What then happens that I get the question to move the database or create a new. No matter which I choose the result is the same, I end up with no database at all. So my question is, is there a reason users can run without a database or should the read-only check prevent trying to move the database in this case?

David
Comment 19 caulier.gilles 2009-05-18 12:20:26 UTC
digiKam cannot run without a sqlite DB file... I think... 

In First Run case, no digiKam DB version 4 file is present. It created to migrate version 3 to 4.

With Collection Setup, it can be different, because a DB version 4 file already exist. But i'm agree, in case of moving DB file to a read only dir, what's happen ? I think digiKam still to use old DB file...

Marcel, can you confirm ?

Gilles Caulier
Comment 20 caulier.gilles 2009-05-19 14:30:57 UTC
To David #18,

I have tested indeep all fixes posted in this report. All work fine now under windows. thanks. I close this report now.

Marcel, 

My question from #19 still valid. Please let's me hear your viewpoint, especially in case of :

1/ Setup collection page
2/ User change DB path.
3/ New DB path do not has already a DB file (DB file is moved)
4/ If new DB path is read only, what's happen ? File cannot be created...

Note: If new DB path has already a DB file, this one is open in read only and user can play with it without to change anything (CDROM archive for ex.)

Gilles Caulier
Comment 21 Marcel Wiesweg 2009-05-19 19:11:10 UTC
This scenario leads to calling of AlbumManager::changeDatabase(). This does some checks and asks the user in a lot of cases. I would not claim everything is perfect there or we couldnt add more checks.
If this is passed, we call bool AlbumManager::setDatabase(). This sets the parameters that it got and does the initialization. If this fails, an error message is displayed, and false is returned. The parameters are set. The calling method - changeDatabase() - could now fall back to the previous setting, which is does not currently.