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!
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
Should be fixed some time ago with the KUrl::path() -> KUrl::toLocalFile() - fixes.
In this case: i there a new build available for Windows?
INstaled a new build: same result. --- seems not to be fixed!
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
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
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!
I can confirm it with ntfs and will do some more debugging in the next days. In the meanwhile another location does work.
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
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
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' ?
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.
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
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
Created attachment 33777 [details] Patch with temporary file as check for read only
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
>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
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
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
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
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.