Free Space on Phone's SD Card Incorrect in Nautilus

Bug #116912 reported by Brian Simons on 2007-05-25
Affects Status Importance Assigned to Milestone
James Henstridge
gnome-vfs-obexftp (Ubuntu)

Bug Description

Binary package hint: gnome-vfs-obexftp

When I view my phone in nautilus using obex://, I can acces the phone's filesystem fine, including the 2 GB SD in it. My phone has about 5 MB free, the SD card is nearly empty. gnome-vfs-obexftp is only reporting the free space in the phone's memory; it does not recognize that the folder that represents the SD card can have a different amount of free space than the phone itself.

The upshot is that I can only copy files over in chunks that are smaller than the amount of free space on the phone.

It seems like this should be reproducible by
- setting up a phone with a micro SD card to work with blutooth
- browsing to the phone in nautilus using obex://
- Checking the free space that nautilus reports
- Navigating to the folder that contains the SD card data
- Verify that the phone memory free space is still being reported, not the SD card free space

I am using gnome-vfs-obexftp 0.2-0ubuntu1 on Feisty.

Daniel Holbach (dholbach) wrote :

Thanks for your bug report.

James: do you have an idea about that? Should I forward the bug to some place?

Changed in gnome-vfs-obexftp:
importance: Undecided → Medium
James Henstridge (jamesh) wrote :

Daniel: I haven't yet set up a place to report bugs in gnome-vfs-obexftp. I should probably register it on Launchpad ...

The obexftp method is just using the free space number for the first memory type.

I notice the bug on my phone: it is returning the free space for the phone even though I have an MMC card. Looking at a directory listing ("obexftp --bluetooth ... --list"), I see that it does tell me the memory type for each item in the root directory:

  <?xml version="1.0"?>
  <!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd"
   [ <!ATTLIST folder mem-type CDATA #IMPLIED> ]>
  <folder-listing version="1.0">
      <folder name="Memory card" user-perm="RW" mem-type="MMC"/>
      <folder name="Images" created="19800101T000008" user-perm="R" mem-type="DEV"/>
      <folder name="Video clips" created="19800101T000008" user-perm="R" mem-type="DEV"/>
      <folder name="Music files" created="19800101T000008" user-perm="R" mem-type="DEV"/>
      <folder name="Graphics" created="19800101T000008" user-perm="R" mem-type="DEV"/>
      <folder name="Tones" created="19800101T000008" user-perm="R" mem-type="DEV"/>
      <folder name="Recordings" created="19800101T000008" user-perm="R" mem-type="DEV"/>

So with this listing, I should be using the "DEV" free space value for "/Images", but the "MMC" free space value for "/Memory card". I've got no idea if there is a more direct way to work this out than listing the parent folder to find the memory type.

So the bug does look fixable, which is good. The alternative would have been to remove the free space calculation code ...

Changed in gnome-vfs-obexftp:
status: Unconfirmed → Confirmed
James Henstridge (jamesh) wrote :

I just had a look at the OBEX spec, and it seems that this mem-type attribute is not part of the standard.

In fact, the inclusion of this attribute in folder listings is the subject of one of Nokia's patent applications (, so it is probably not found on other manufacturers phones.

Changed in gnome-vfs-obexftp:
assignee: nobody → jamesh
status: Unconfirmed → Confirmed
Changed in gnome-vfs-obexftp:
importance: Undecided → Medium
James Henstridge (jamesh) wrote :

I've made the above change, which seems to work at the GNOME-VFS level:

    >>> import gnomevfs
    >>> bda = '00:0E:ED:...'
    >>> def free_space(path):
    ... uri = gnomevfs.URI('obex://[%s]%s' % (bda, path))
    ... return gnomevfs.get_volume_free_space(uri)
    >>> free_space('/')
    >>> free_space('/Images/')
    >>> free_space('/Memory%20card/')

However, I am still seeing 4.6MB free space when browsing "Memory card" in Nautilus, so there is probably something else I need to do to get it working in Nautilus.

Changed in gnome-vfs-obexftp:
status: Confirmed → In Progress
James Henstridge (jamesh) wrote :

Just tried restarting Nautilus again, and things started working. Nautilus now shows 25.2MB free on the memory card, and it let me copy a file to the memory card that wouldn't fit on the phone's memory.

So this bug will be fixed for the 0.3 release (provided you have a Nokia phone, or one that provides the same data in folder listings).

Changed in gnome-vfs-obexftp:
status: In Progress → Fix Committed
James Henstridge (jamesh) wrote :

Fixed in the 0.3 release.

Changed in gnome-vfs-obexftp:
status: Fix Committed → Fix Released
Daniel Holbach (dholbach) wrote :

gnome-vfs-obexftp (0.3-0ubuntu1) gutsy; urgency=low

  * New upstream release:
    - Sync osso-gwobex and osso-gnome-vfs-extras changes from Maemo
    - Instead of asking hcid to set up the RFCOMM device for communication,
      use an RFCOMM socket directly. This is both faster and doesn't require
      enabling experimental hcid interfaces.
    - Improve free space calculation for Nokia phones with multiple memory
      types (e.g. phone memory and a memory card).
      Now the free space for the correct memory type for a given directory
      should be returned. This fixes various free-space dependent operations
      in Nautilus such as copying files. (LP: #116912)
    - debian/copyright: updated. (LP: #120146)
    - debian/
      - added libbluetooth-dev (>= 3.7) to Build-Depends.
      - changed Maintainer field.

 -- Daniel Holbach <email address hidden> Wed, 13 Jun 2007 09:00:05 +0200

Changed in gnome-vfs-obexftp:
status: Confirmed → Fix Released
Mattias Eriksson (snaggen) wrote :

I have tried both 0.2 and 0.3 with my SonyEriksson z710. Both versions report 0 bytes free space, so I can't copy anyting to the phone. I tried 0.2 with my old phone K610 and that worked, but that phone didn't have a memory card.

So in short... this bug still is valid for new SonyEricsson mobiles with memory cards

Daniel Holbach (dholbach) wrote :

Did you try to restart nautilus? Did you pair the phone with your machine properly?

Changed in gnome-vfs-obexftp:
status: Fix Released → Needs Info
Mattias Eriksson (snaggen) wrote :

Just to be sure I tested again and restarted everyting (including phone, nautilus, bluez, gnome-vfs-daemon) and still not working.
The phone is paired, and I can access the phone and browse the content, copy from the phone to the desktop but not to the phone.

Mattias Eriksson (snaggen) wrote :

I don't know if it helps, but it seems that there are no mem-type specified on this phone....

obexftp --bluetooth 00:16:B8:75:7F:34 --list
Browsing 00:16:B8:75:7F:34 ...
Channel: 7
Receiving "(null)"... <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE folder-listing SYSTEM "obex-folder-listing.dtd">
 XML Coder, (C) 2001 Sony Ericsson Mobile Communications AB
<folder-listing version="1.0"><folder name="Telefonminne"/>
<folder name="Memory Stick"/>

James Henstridge (jamesh) wrote :

Matthias: I don't think your problem is related to this bug report -- this one is about distinguishing what volume a particular directory resides on and returning the appropriate free space. Your one sounds more like faulty reporting of free space.

I've heard of a few other people having trouble with Sony phones, but don't have the hardware to debug it. If you would like to help me debug the problem, I suggest opening a new bug report. I've got a few commands you could run to collect data that would be useful in tracking down the problems.

Mattias Eriksson (snaggen) wrote :

Ok, opened the bug 120214

Daniel Holbach (dholbach) wrote :

Closing the bug report.

Changed in gnome-vfs-obexftp:
status: Needs Info → Fix Released
quikcowboy (quikcowboy) wrote :

I Had a similar problem with a Sony Ericsson W595 with a 2GB M2 memory card, and resorted to purchasing a external card reader for a few pounds. I do have to admit this was an easy way out and avoided correcting the real problem. :(

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers