Version: 1.0.0 (using 4.3.4 (KDE 4.3.4) "release 2", KDE:43 / openSUSE_11.0) Compiler: gcc OS: Linux (i686) release 2.6.25.20-0.5-default Steps to reproduce: 1) Mount a CIFS volume, and set it up as an image repository in DK 2) Connect a camera 3) Transfer images to that volume using the camera import wizard 4) Inspect the file-system from the command-line As well as the imported images, there is then a cifsxxxx file for each transferred image (but not movie files, based on file counts). For those that were automatically rotated (via EXIF info), this file will actually be a copy of the _unrotated_ image. For all others the the cifsxxxx file will be empty (0 bytes). That is the import proceeds correctly, and the images are transferred fine. But the existence of cifsxxxx files suggests that in someway DK is not cleaning up after itself properly (perhaps not closing files properly or something?)
Oh, and this didn't used to happen in DK 0.10...
Very sorry, just realised that I never gave an example of what I mean by cifsxxxx! --------------------------- #> cd <my-photo-dir> #> ls -1s 3296 cifs2b9 0 cifsf0a3 0 cifsf8f 0 cifsf9b9 0 cifsfdd2 3008 IMG_8494.JPG 3824 IMG_8506.JPG 4080 IMG_8507.JPG 3296 IMG_8508.JPG 4224 IMG_8509.JPG -------------------------- Where the cifs2b9 file is an unrotated version of IMG_8508.JPG
I suspect that cifs files are temp files generated by KDE api. it's used by digiKam to transfert files from device. Gilles Caulier
This still reproducible using digiKam 2.0.0 ? Gilles Caulier
Michael, This file still valid using digiKam 2.4 ? Gilles Caulier
Still valid?
Michael, This file still valid using last digiKam 4.2.0 ? Gilles Caulier
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ? Gilles Caulier
With digiKam 5.0.0, this problem is not reproducible. I close this file now. Don't hesitate to re-open if necessary. Gilles Caulier