Skip to content

gphotofs 0.1

First off, I’d like to thank hub for letting me put gphotofs in gphoto cvs.

Second, I’ve rolled out a 0.1 release. There’s no big new feature, but it works quite a bit better than the previous one. You can still only read files and delete them but now deletes are not ridiculously slow and it won’t ignore errors from libgphoto2. So, all in all, it’s a very usable release.

But now, to the help bit: in their infinite wisdom, Canon have only partially implemented the Picture Transfer Protocol on my camera (and probably all of their cameras). This means that you can’t upload any files to it, which limits my abilitiy to implement write support into gphotofs. Mind you, with the disk backend that hub just checked in, it would be possible to do some developement on this feature without camera support as it appears to work with any mount point. Anyway, if anyone has a less crippled camera and wants to look at this, please do. As I alluded to yesterday, it will require a way to safely and efficiently implement the caching required to map incremental block writes to ‘atomic’ file uploads. Now that the source is in gphoto’s cvs, it’ll be a lot easier for other people to work with.

To make things more consistent, I’ve moved the release directory to my server here, but I hope that we can get them on the sourceforge page too.


{ 27 } Comments

  1. Hub | 29th December 2005 at 14:44 | Permalink

    I have uploaded it to gphoto files

  2. Christian Faulhammer | 8th February 2006 at 04:42 | Permalink

    Do you need more help for the writing capabilities?

  3. Philip Langdale | 8th February 2006 at 08:08 | Permalink

    Yes, I do. There was someone who visited #gphoto and had basic write support working but he never submitted a formal patch. The approach unavoidably ends up being that the file write must be fully cached in ram until the file is closed, at which point it can be uploaded to the camera. It’s rather fragile and memory inefficient, but should work.

  4. Christian Faulhammer | 10th February 2006 at 06:26 | Permalink

    Unfortunately I am no programmer (at the moment even short in time) but I have an iRiver T10 and a Canon Powershot A300 to help you test the write support. Any suggestions how I might help?

  5. Philip Langdale | 12th February 2006 at 12:36 | Permalink

    It would be good to track down the person who had this patch and then work with them to test it. I can’t do much good here. I’ll see if I can find them again.

  6. Marcin Kulik | 3rd April 2006 at 14:58 | Permalink

    Hello. I’m not that person from #gphoto but i’ve also implemented write support. I have iriver t30 player and i wanted to be able to put some mp3s on it, so i’ve been hacking gphotofs for two evenings. And it almost works. And yes, the file must be cached whole somewhere, i’m caching it in /tmp dir. But libgphoto has probably some limitation about transfered file size, almost every attempt to transfer file over 10MB of size gives some libgphoto error. I don’t have much time now to work with this but I can send you my work so far, hope it will help someone.

  7. Philip Langdale | 3rd April 2006 at 23:30 | Permalink

    Marcin, please do. Although I can’t test it, I can at least look at the code and we can work on merging it in.

  8. Marcin Kulik | 4th April 2006 at 12:59 | Permalink

    Ok, so drop me an email to sikkill(at), so I can send you my work.

  9. Catalin Nicolescu | 6th April 2006 at 09:49 | Permalink

    First of all I’d like to congratulate you on your work. Keep it up.
    Second, I’d like to help in testing and debuging. I can manage my way around the code, not very experienced but I think I could be of some help. On the Canon issue, I have a Canon A520 (working with gphoto2 PTP mode) and I’d like to help test the gphotofs. If you can please tell me where to send feedback and debug_info. Thanks.

  10. Philip Langdale | 6th April 2006 at 19:51 | Permalink


    If you have a Canon camera, then gphotofs is basically already providing everything it can. The canon’s don’t support file upload. So go download it and try it out.

  11. Pavel Benak | 18th April 2006 at 11:27 | Permalink

    This project is great. I’d like to help, too. I’m a beginner C programmer (I’m programming in Java), but I would like to help some way (e.g. by testing). My camera is same as Catalin has – Canon PowerShot A520. Bye

  12. TheOldFellow | 2nd May 2006 at 00:12 | Permalink

    I just tried version 0.2 on my Linux- system (fuse compiled in, not modular), and it works fine for a cp -a, but hangs when I try ls on the gphotofs mount point. The project has great promise, thanks.

  13. Philip Langdale | 2nd May 2006 at 08:05 | Permalink

    That’s somewhat surprising. Does it consistently fail on ls? or only when you do multiple things on the same mount point? If you can drop by #gphoto on freenode, we can try and investigate.

  14. 1blade22 | 15th July 2006 at 08:37 | Permalink

    This project is indeed very great!
    There hasn’t been much around lately? will there be a 0.3 ?

  15. Philip Langdale | 20th July 2006 at 22:02 | Permalink

    Well, from a read-only point of view, the project is basically done. The main reason for a 0.3 is write support. I do have Marcin’s patch but I’ve been swamped with other things and haven’t been able to evaluate it properly (and I certainly can’t test it!). I should probably do a test build so people can test it out.

  16. kamome | 2nd September 2006 at 17:00 | Permalink


    THX for gphotofs! But I’m having some trouble:

    As a user I get:
    # gphotofs tstdir/
    fuse: failed to exec fusermount: Permission denied

    As root it works – now, how do I unmount the thing?

    Now I did, again as root, with tstdir still mounted:
    # gphotofs tstdir2 -o “umask=022 uid=1000 gid=1000″
    But then “ls tstdir2″ says:
    ls: lese Verzeichnis tstdir2: Numerical result out of range
    (reading directory tstdir2)

    So, really looks promising – but how do I mount as a user, how do I unmount? TIA


  17. kamome | 2nd September 2006 at 17:04 | Permalink

    OK, forget about the unmounting… of course, with umount :)

  18. Philip Langdale | 2nd September 2006 at 17:06 | Permalink

    You should mark the /dev/fuse device node as 666 or whatever other method you want to allow your regular user to use it. Also, you should use ‘fusermount -u’ to unmount as a regular user.

    As a separate problem, libgphoto2 needs access to the usb nodes in /proc (or /sys with newer versions I think) and these might require root access too.

  19. Gerard van Draanen | 29th March 2007 at 12:16 | Permalink

    Good work on the fuse, gphotofs.

    See , where I’m trying to get someone to cross-compile the needed modules for my Asus WL-HDD, for it to connect with my Creative Zen Vision:M.

    Would you consider the gphotofs project ‘done’ and stable for read/write ? Or is it still progressing ?

    Could you be tempted to assist Oleo in getting a proper cross-compile of fuse and gphotofs into the NSLU2/Optware environment ? (See references in the same thread)


  20. Philip Langdale | 29th March 2007 at 18:30 | Permalink

    Hi Gerard,

    Marcus feels that write support is ready. He’s merged it from the write development branch to the trunk in svn. As such, the next gphotofs release will include write support. However, that release can’t happen until the next libgphoto release as the gphotofs code needs it.

    I do not know when this release will be, however.

    I’m not in a position to get involved with this porting work directly, but getting the fuse userspace and libgphoto/gphotofs ported should be straight forward.

  21. Gerard van Draanen | 4th April 2007 at 01:52 | Permalink

    See if I understand,
    gphotofs is considered ‘stable’ in its “next” release
    but it is waiting for the “next” release of libgphoto.
    Porting should be straight forward.

    I’d say
    no estimate/plan is available for “next” release of libgphoto, which is needed to arrive at “next” gphotofs.
    Porting “now” is useless, and not supported by team.

    I’ll keep an eye open for future releases…
    Such is the world of opensource.

  22. Joey | 6th April 2007 at 06:44 | Permalink

    Hi guys! I did a fork of gphotofs yesterday and implemented write support. I do not know if it works with libgphoto2 or not because I still run into some problems using fuse: Whatever I do a command like “cp ” fails with the message “function not implemented” in the shell. I did some debugging and found that cp will do some (fuse)getattr and (fuse)readdir and that’s it – no call to (fuse)open as I would have expected. In other words: What do I have to do so that a command like cp will call (fuse)open?

    I am a senior software developer. I suggest we join forces to get gphotofs an libgphoto2 up and running. Either your version or my fork – I don’t care. I have a iRiver T10 here and want to upload files on to it. gphotofs may help me greatly in doing so – all attempts to do this under Microsoft Windows failed until now. I will never buy anything from iRiver again or any company that cooperates with Microsoft in such a way like iRiver does.

    I am living i Germany if that helps …. please contact me as soon as possible using my email address jk*at*

    Thank you!

  23. Philip Langdale | 6th April 2007 at 07:30 | Permalink

    Write support is done. If you get libgphoto2 and gphotofs from svn, you’ll have it. The next official releases should occur soon.

  24. Simon Phillips | 18th July 2007 at 01:31 | Permalink


    A family member has a Samsung K3 MP3 player, which reputedly uses MTP. I am trying to configure up my Linux box so that it will write to it, so I can load some songs onto it, and would like to grab a copy of gphotofs with write support. Unfortunately I’ve never used subversion so wouldn’t really know where to start grabbing snapshots of gphotofs from there. Any chance of putting up a snapshot on the web so I can download and try it out?


  25. LudoA | 8th December 2008 at 15:03 | Permalink


    I’m using gphotofs, and it’s working perfectly in that just typing “gphotofs /mnt/usb” automatically mounted my Canon PowerShot A75. However, I’d like to create a dump of the CF card, so that I can run a data recovery tool on it. Is this possible using fuse?



  26. Philip Langdale | 8th December 2008 at 18:31 | Permalink

    If you need to actually dump the card, then you’ll want to get a CF card reader (you can get a cheap multi-slot usb reader from almost anywhere). The camera abstracts too much for you to be able to do a dump through it.

  27. LudoA | 9th December 2008 at 00:18 | Permalink

    Okay, thanks a lot for the response. I was hoping to be able to do it in software, as getting a hardware reader for this probably one-time recovery is a bit silly… No such luck I guess. Thanks for creating gphotofs btw, it’s very slick.

    IMHO it makes sense to have a driver in the kernel which exposes PTP like a mass storage device. This was much more applications could use these cameras, and camera tools could still optionally support PTP in order to get PTP’s extra features (though AFAIK the only feature is that it can get thumbnails without transmitting the entire picture, like you’d have to do with USB mass-storage device cameras). There actually used to be such a kernel driver, though it was never in the main tree, and it was for 2.4… maybe someone with the necessary skill will one day port it, who knows.

    Thanks again for your quick reply, much appreciated.