Since some months ago, Debian's gphoto2 stopped being able to delete photos (with --delete-file command). It used to work before.

Judging from the error message (see below for a typical error message), Debian's gphoto2 is always looking at the / directory to delete photos, even if the files are elsewhere. Note that both --list-files and --get-file work flawlessly; *only* --delete-photo is broken.


{acli@tea:~}$ gphoto2 --get-file 261
Detected a 'Canon:PowerShot G2'.
Downloading 'IMG_2341.JPG' from folder '/DCIM/123CANON'...
Saving file as IMG_2341.JPG
{acli@tea:~}$ LANG=C gphoto2 --delete-file 261
Detected a 'Canon:PowerShot G2'.

*** Error ***
There are no files in folder '/'.
*** Error (-2: 'Bad parameters') ***

For debugging messages, please use the --debug option.
Debugging messages may help finding a solution to your problem.
If you intend to send any error or debug messages to the gphoto
developer mailing list <gphoto-devel@lists.sourceforge.net>, please run
gphoto2 as follows:

    env LANG=C gphoto2 --debug --delete-file "261"

Please make sure there is sufficient quoting around the arguments.

{acli@tea:~}$

Ambrose Li wrote:

I just checked gphoto2 manpage (from upstream, not that there are
modifications to the manpage in the Debian package) in CVS and as back
as Revision: 1.1, Mon Aug 19 12:57:07 2002 UTC (2 years, 4 months ago),
the manpage had "No recursion (default for deletion)".

If you can point me to a package (the whole history is available on
http://snapshot.debian.net/) who deleted recursively by default I will
be happy to point you it was certainly a bug.

By the way feel free to reopen this bug and mark it as wishlist "I
wish I had not to tell -R to get recursive behaviour".


Thanks,

        Frederic

Hi,

this has nothing to do with recursion. I cannot delete *any* photo
with current gphoto2.

(See my example; I was trying to delete only 1 file.)

I didn't even know recursion is possible.

Also, if delete-file implies recursion, I also didn't know how to
specify the directory in the camera; in any case get-file can find
the file, and it was working until some months ago.

Ambrose Li wrote:

Sure.  In a directory.  In its default behaviour delete won't look
in directories.

Actually gphoto2 should give distinct numbers to file in different
directories so it is not a problem.  And get-file finds the file
*because* (once again quoting the manpage) recursion is default
behaviour for non-destructive commands (list and get).



        Frederic

:-/

Does any camera not store files in directories? I don't know of any...

Sigh :-(

Perhaps the man page should say this more prominently. This certainly
will confuse *old* users.... I have been using gtkam to delete files or
delete them at home (where it runs an older and more sane version of
gphoto2...)

If gtkam preserves timestamps I would have stopped using gphoto2 long
time ago...

I have been using gphoto2 ever since I bought my camera (more than a
year ago) and it had always deleted photos for me, even after I started
using Debian. It stopped working only recently, and I will be very
skeptical that it has been a "bug" for over a year, especially since
the old "buggy" behaviour makes perfect sense (in the context of how
files are specified in gphoto2, what --help says, etc.) whereas the
new behaviour does not make any sense at all.

If the intent was to prevent the user from deleting the wrong files,
this is certainly the wrong way to do it. There's no way for me to
specify a directory or any file name (it took me a while to figure
out how to specify file *numbers*); the notion of "recursion" is
completely meaningless from the user's viewpoint... :-(

When I get back to the office tomorrow I'll try pulling stuff from
snapshots... I will tell you when the bug appeared (i.e., when
"recursion mode" began to have to be specified...)

Ambrose Li wrote:

As I said this looks like default gphoto2 behaviour for as long as CVS
history can tell.  Could you tell me what is this "older and more sane
version of gphoto2" ?

gphoto2 (2.0final-4), packaged in woody, had the same behaviour.


        Frederic

Hello,
is there any progress on this report? The way gphoto2 behaves is quite
obviously wrong:

Hi,

I have just seen the same issue ! I can't more delete photos on my PTP camera
:(

I have read the gphoto2 code and compared with the previous release. And it's a
regression.

I have checked, and it's fixed in the new gphoto2 release.

For CANON camera users, to make quickly :

$ cd /usr/local/src/
$ mkdir gphoto2
$ cd gphoto2
$ apt-get source libgphoto2-2
$ apt-get build-deps libgphoto2-2
$ cd libgphoto2-2

Then, apply the modification :
--- camlibs/canon/library.c.old 2010-07-22 22:26:58.000000000 +0200
+++ camlibs/canon/library.c     2010-07-22 22:27:28.000000000 +0200
@@ -1101,6 +1101,8 @@
        (*sinfos)->capacitykbytes = camera->pl->cached_capacity / 1024;
        (*sinfos)->fields |= GP_STORAGEINFO_FREESPACEKBYTES;
        (*sinfos)->freekbytes = camera->pl->cached_available / 1024;
+       (*sinfos)->fields |= GP_STORAGEINFO_ACCESS;
+       (*sinfos)->access = GP_STORAGEINFO_AC_READONLY_WITH_DELETE;
        return GP_OK;
 }

And rebuild package :

$ debuild -us -uc


Otherwise, we have to wait a new package release.

Regards,

Nicolas