Files: [Juno + Hera] Files does not mount iPod in the desired way (wrong protocol)

Created on 4 Dec 2019  Â·  36Comments  Â·  Source: elementary/files

Prerequisites

  • [X] I have searched open and closed issues for duplicates.

Describe the bug

When mounting an iPod (in this case, 2nd-gen iPod Touch, 2009), Files uses the gphoto:// protocol, mounting it as a Photo device (only DCIM folder is visible), instead of using the afc://{ipod_uuid} protocolol, which makes music files accesible.

To Reproduce

Steps to reproduce the behavior:

  1. Connect iPod
  2. Mount iPod
  3. Access iPods's file panel
  4. Check protocol on the address bar (e.g. gphoto2://[usb:002,004]/)
  5. Open Terminal and type idevicepair pair
  6. Copy the iPod's resulting UUID
  7. In Files, replace gphoto://... with afc://{resulting UUID number}
  8. See that the iPod's actual filesystem is now accesible

Expected behavior

Connecting the iPod should result in Files using the afc:// protocol to sync music with Noise or Rhythmbox instead of mounting it as a camera using the gphoto:// protocol.

Platform Information

  • OS: elementary OS
  • OS Version: Juno
  • Hardware info:

    • System: ThinkPad T410s
    • iPod: 2nd-gen Touch

    • [ ] I'm using the latest version from git that I've manually compiled

    • [X] I'm using the latest released stable version

All 36 comments

This part of Files has not been updated for a while so does not specifically recognise afc protocol but it looks like after mounting manually, it can browse this protocol OK. I think it is gvfs that decides what to mount the device as when it automounts - Files just notices that it has been mounted. It looks like the iPod is mounted as two locations - one under "Devices" (automounted as a camera) and one under "Network" (manually mounted as a server). Servers are not automounted.

Can you see the iPod in the "Entire Network" view (before manual mounting)? We may have to extend the "Connect to Server" dialog to include afc protocol or add a plugin to handle mounting Apple mobile devices. Unfortunately I do not have one of these devices so it really needs a dev with a knowledge of afc to fix this.

I found this info here https://reincubate.com/support/how-to/mount-iphone-files/

OS automatically presents modern devices as cameras when they're connected over USB. This uses Picture Transfer Protocol (PTP) which is a fairly limited system allowing you to copy photos back and forth. You'll probably recognise the DCIM folders that photos tend to appear in.

Right, upon physically connecting the iPod, Files shows 2 locations: iPod (showing the _DCIM_ folder through gphoto:// protocol) and iPod Documentation (which is unusable).

The ideal would be to recognize the iPod as music player and enable the afc:// protocol immediately to transfer files via _Noise_ or _Rhythmbox_ (which used to work well in Loki without extra configuration). I haven't found the way to force gvfs into that mode yet.

I'm not sure if a breaking change was introduced in _Ubuntu 18.04_, but the device hasn't worked again ever since.

Jailbreaking the device isn't an option anymore, as I'm not running Windows nor OSX, and last time I tried the procedure, I got a weird volume glitch that had to be corrected by a low-level Apple firmware installation (done while I was working at a local Apple Premium Reseller's tech service).

The information provided on that link deals mostly with forensic needs, not so much with a common music/data sync procedure the way iTunes works (and by extension, _Banshee_, _Rhythmbox_ and _Noise_), which used to be no problem under _Ubuntu 16.04_ and _elementaryOS Loki_.

If you or anyone you know have any other idea about where the problem could lie, I'll try it and report back.

Intersting that you do get two mounts when you plug the iPod in. Where is the "iPod Documentation" one shown in the sidebar - under Devices or under Network? If you right click on it and choose Properties what info do you get?

Under _Devices_, right above _iPod_ (on the screenshot, it's shown as _"Documentación sobre..."_).

If I right-click on _iPod Documentation_ to check _Properties_, I get the following information:


When checking the address bar after selecting _iPod Information_, the following address is shown:
afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb:3/

If I remove the trailing :3/ and press _Enter_ (making the address afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb), the iPod's filesystem is accessible in the way music players such as _Noise_, _Rhythmbox_ and _Banshee_ should see it to be able to sync music and other files.


Note that after mounting the iPod as afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb (the only accessible written form), it's not shown just under _Devices_ (_"Dispositivos"_ in spanish) but under _Network_ (_"Red"_). The mount point under _Devices_ is unusable in its current form.

Perhaps the trailing :3/ after afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb could be misinterpreted at mount time, obscuring filesystem access to both _Files_ and music players.

The _iPod_ mount point under _Network_ is invisible to music players, so even if correctly mounted, no sync is possible.
The _iPod_ mount point under _Devices_ is visible to music players but incorrectly mounted, so no sync is possible.

OK, thanks - thats helpful. I'll check the Files code to see if it is mishandling the slightly odd URIs the iPod seems to produce when automounted by gvfs.

@dennismayr There is a PR (#1184) awaiting review, but it needs an iPod user to test it. If you or anyone else experiencing the problem are able to build that branch and confirm whether it fixes the issue that would be helpful, thanks.

I'm not sure how to build the branch, but I could try if the instructions are there

Thanks Dennis. There is some info on building from source in the README.md here: https://github.com/elementary/files and more detailed info here: https://docs.elementary.io/develop/writing-apps/untitled/the-build-system.

You should get what you need with sudo apt install elementary-sdk and sudo apt build-dep io.elementary-files. You will need to clone the Files repository onto your local machine, using git, and switch to the afc-protocol branch before building and installing it.

Make sure you close any existing Files windows before running the PR.

Will do; there's, however, a thing:
sudo apt build-dep io.elementary-files says that there's no io.elementary-files package.

sudo apt build-dep pantheon-files does go through.
After running that, cloning the Files repo, and then git checkout afc-protocol, meson build --prefix=/usr, cd build and ninja, I get the following error message before building fails:

[13/137] Compiling C object 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o'.
FAILED: libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o 
cc -Ilibcore/342de7f@@pantheon-files-core@sha -Ilibcore -I../libcore -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/gee-0.8 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/granite -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -w -g '-DGETTEXT_PACKAGE="io.elementary.files"' -w -ggdb3 -O0 -std=c99 -Wall -Werror -fPIC -D_REENTRANT -pthread  -MD -MQ 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o' -MF 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o.d' -o 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o' -c 'libcore/342de7f@@pantheon-files-core@sha/File.c'
/home/dmayr/BUILD_AREA/files/libcore/File.vala: In function ‘gof_file_get_permissions_as_string’:
/home/dmayr/BUILD_AREA/files/libcore/File.vala:735:21: error: ‘S_ISVTX’ undeclared (first use in this function); did you mean ‘__S_ISVTX’?
         bool sticky = (permissions & Posix.S_ISVTX) != 0;
                     ^~~~~~~
                     __S_ISVTX
/home/dmayr/BUILD_AREA/files/libcore/File.vala:735:21: note: each undeclared identifier is reported only once for each function it appears in
[18/137] Compiling C object 'libcore/342de7f@@pa...n-files-core@sha/meson-generated_FileUtils.c.o'.
ninja: build stopped: subcommand failed.

Sorry, my mistake - it should be sudo apt build-dep pantheon-files as you have found. I've never seen that build error - it looks like one of the libraries is the wrong version - presumbaly 'libc'. I notice you are on Juno (or were in Dec 2019) whereas the part of the code causing the error was developed on Hera - which could explain it. Any chance of upgrading to Hera stable?

I am actually running Hera stable (5.1.4), and also puzzled.

What version of vala do you have? I have 0.40.22.

I have 0.40.22 too, fresh Hera install

This the output from meson re dependencies when I build:

The Meson build system
Version: 0.49.2
Source dir: /media/jeremy/Shared/shared_data/Vala/Elementary/pantheon-files-branches/files
Build dir: /media/jeremy/Shared/shared_data/Vala/Elementary/pantheon-files-branches/files/build
Build type: native build
Project name: io.elementary.files
Project version: 4.4.2
Native C compiler: cc (gcc 7.5.0 "cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0")
Native Vala compiler: valac (valac 0.40.22)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Dependency glib-2.0 found: YES 2.56.4
Dependency gobject-2.0 found: YES 2.56.4
Dependency gio-2.0 found: YES 2.56.4
Dependency gio-unix-2.0 found: YES 2.56.4
Dependency gmodule-2.0 found: YES 2.56.4
Dependency gee-0.8 found: YES 0.20.2
Dependency gtk+-3.0 found: YES 3.22.30
Dependency granite found: YES 5.5.0
Dependency pango found: YES 1.40.14
Dependency sqlite3 found: YES 3.22.0
Dependency libcanberra found: YES 0.30
Dependency libnotify found: YES 0.7.7
Library posix found: YES
Library linux found: YES
Library m found: YES
Dependency unity found: YES 7.1.4
Dependency plank found: YES 0.11.89
Dependency zeitgeist-2.0 found: YES 1.0
Configuring config.h using configuration
Library pantheon-files-core-C found: YES
Library marlin found: YES
Configuring io.elementary.files.service using configuration
Configuring io.elementary.files.Filemanager1.service using configuration
Configuring io.elementary.files-pkexec using configuration
Configuring io.elementary.files.policy.in using configuration
Configuring io.elementary.files.desktop.in using configuration
Configuring io.elementary.files.appdata.xml.in using configuration
Dependency cloudproviders found: YES 0.3.0
Dependency libgit2-glib-1.0 found: YES 0.26.2

How does that compare to yours?

It all seems to match

The Meson build system
Version: 0.49.2
Source dir: /home/dmayr/BUILD_AREA/io.elementary-files
Build dir: /home/dmayr/BUILD_AREA/io.elementary-files/build
Build type: native build
Project name: io.elementary.files
Project version: 4.4.2
Native C compiler: cc (gcc 7.5.0 "cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0")
Native Vala compiler: valac (valac 0.40.22)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Dependency glib-2.0 found: YES (cached)
Dependency gobject-2.0 found: YES (cached)
Dependency gio-2.0 found: YES (cached)
Dependency gio-unix-2.0 found: YES (cached)
Dependency gmodule-2.0 found: YES (cached)
Dependency gee-0.8 found: YES (cached)
Dependency gtk+-3.0 found: YES (cached)
Dependency granite found: YES (cached)
Dependency pango found: YES (cached)
Dependency sqlite3 found: YES (cached)
Dependency libcanberra found: YES (cached)
Dependency zeitgeist-2.0 found: YES (cached)
Dependency libnotify found: YES (cached)
Library posix found: YES
Library linux found: YES
Library m found: YES
Dependency unity found: YES (cached)
Dependency plank found: YES (cached)
Configuring config.h using configuration
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Library pantheon-files-core-C found: YES
Library marlin found: YES
Configuring io.elementary.files.service using configuration
Configuring io.elementary.files.Filemanager1.service using configuration
Configuring io.elementary.files-pkexec using configuration
Configuring io.elementary.files.policy.in using configuration
Configuring io.elementary.files.desktop.in using configuration
Configuring io.elementary.files.appdata.xml.in using configuration
Dependency cloudproviders found: YES (cached)
Dependency libgit2-glib-1.0 found: YES (cached)
Program meson/post_install.py found: YES (/usr/bin/env python3 /home/dmayr/BUILD_AREA/io.elementary-files/meson/post_install.py)
Build targets in project: 25

Looks like you dependencies are coming from a cache so you cannot tell which version is being used. Not sure what cache that is but it needs to be disabled.

There is a meson option to clear its cache. https://mesonbuild.com/Release-notes-for-0-38-0.html#add-option-to-mesonconf-to-wipe-cached-data:

Meson caches the results of dependency lookups. Sometimes these may get out of sync with the system state. Mesonconf now has a --clearcache option to clear these values so they will be re-searched from the system upon next compile.

The article mentions mesonconf, unavailable both as system binary or repo package.
Guessing it's just meson, running meson --clearcache yields an error message on my machine:

meson: error: unrecognized arguments: --clearcache

Either the meson version available in _elementary OS_ doesn't include the option anymore (installed version: 0.49.2, article version: 0.38.0), or something else is up.

_Edit:_ Just found out what's up.

Manpages for Ubuntu 18.04

This  executable  is  deprecated and will be removed in the future. The functionality that
       was in this executable can be invoked via the main Meson command like this:

       meson configure <options>

I'm giving it another try.

Here are the uncached dependencies:

$ meson build --prefix=/usr --reconfigure
The Meson build system
Version: 0.49.2
Source dir: /home/dmayr/BUILD_AREA/io.elementary-files
Build dir: /home/dmayr/BUILD_AREA/io.elementary-files/build
Build type: native build
Project name: io.elementary.files
Project version: 4.4.2
Native C compiler: cc (gcc 7.5.0 "cc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0")
Native Vala compiler: valac (valac 0.40.22)
Build machine cpu family: x86_64
Build machine cpu: x86_64
Found pkg-config: /usr/bin/pkg-config (0.29.1)
Dependency glib-2.0 found: YES 2.56.4
Dependency gobject-2.0 found: YES 2.56.4
Dependency gio-2.0 found: YES 2.56.4
Dependency gio-unix-2.0 found: YES 2.56.4
Dependency gmodule-2.0 found: YES 2.56.4
Dependency gee-0.8 found: YES 0.20.2
Dependency gtk+-3.0 found: YES 3.22.30
Dependency granite found: YES 5.4.0
Dependency pango found: YES 1.40.14
Dependency sqlite3 found: YES 3.22.0
Dependency libcanberra found: YES 0.30
Dependency zeitgeist-2.0 found: YES 1.0
Dependency libnotify found: YES 0.7.7
Library posix found: YES
Library linux found: YES
Library m found: YES
Dependency unity found: YES 7.1.4
Dependency plank found: YES 0.11.89
Configuring config.h using configuration
Library pantheon-files-core-C found: YES
Library marlin found: YES
Configuring io.elementary.files.service using configuration
Configuring io.elementary.files.Filemanager1.service using configuration
Configuring io.elementary.files-pkexec using configuration
Configuring io.elementary.files.policy.in using configuration
Configuring io.elementary.files.desktop.in using configuration
Configuring io.elementary.files.appdata.xml.in using configuration
Dependency cloudproviders found: YES 0.3.0
Dependency libgit2-glib-1.0 found: YES 0.26.2
Program meson/post_install.py found: YES (/usr/bin/env python3 /home/dmayr/BUILD_AREA/io.elementary-files/meson/post_install.py)
Build targets in project: 25
Found ninja-1.8.2 at /usr/bin/ninja

Running ninja again in the build subdirectory yields this message:

$ cd build

# dmayr @ ThinkPad in ~/BUILD_AREA/io.elementary-files/build on git:afc-protocol o [16:34:54] 
$ ninja
[2/100] Compiling C object 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o'.
FAILED: libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o 
cc -Ilibcore/342de7f@@pantheon-files-core@sha -Ilibcore -I../libcore -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/gee-0.8 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/granite -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -w -g '-DGETTEXT_PACKAGE="io.elementary.files"' -w -ggdb3 -O0 -std=c99 -Wall -Werror -fPIC -D_REENTRANT -pthread  -MD -MQ 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o' -MF 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o.d' -o 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o' -c 'libcore/342de7f@@pantheon-files-core@sha/File.c'
/home/dmayr/BUILD_AREA/io.elementary-files/libcore/File.vala: In function ‘gof_file_get_permissions_as_string’:
/home/dmayr/BUILD_AREA/io.elementary-files/libcore/File.vala:735:21: error: ‘S_ISVTX’ undeclared (first use in this function); did you mean ‘__S_ISVTX’?
         bool sticky = (permissions & Posix.S_ISVTX) != 0;
                     ^~~~~~~
                     __S_ISVTX
/home/dmayr/BUILD_AREA/io.elementary-files/libcore/File.vala:735:21: note: each undeclared identifier is reported only once for each function it appears in
[7/100] Compiling Vala source ../libwidgets/Interfaces/LocatableInterface.vala ../libwid..../libwidgets/Resources.vala ../libwidgets/Welcome.vala libcore/pantheon-files-core.vapi.
zeitgeist-2.0.vapi:112.3-112.42: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
        public abstract async void notify_delete ([DBus (signature = "(xx)")] GLib.Variant time_range, uint32[] event_ids) throws GLib.IOError;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
zeitgeist-2.0.vapi:77.3-77.34: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
        public abstract string get_state () throws GLib.IOError;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
zeitgeist-2.0.vapi:84.3-84.30: warning: DBus methods are recommended to throw at least `GLib.Error' or `GLib.DBusError, GLib.IOError'
        public abstract uint32 state () throws GLib.IOError;
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
../libwidgets/View/SearchResults.vala:1130.27-1130.35: warning: `Gdk.Color' has been deprecated since 3.14
Compilation succeeded - 4 warning(s)
ninja: build stopped: subcommand failed.

Sorry for referencing an out-of-date page :-( .
The only difference in the dependencies I can see is the Granite version (which I compiled from source a few days ago) but there have been no relevant changes since 5.4.0 was release 15 days ago.

The branch passes CI testing for building on GitHub so there must be something different about your system but I am puzzled what.

@dennismayr One of the devs in elementary slack suggests you post the output of:

cat /usr/include/linux/stat.h | grep S_ISVTX

it may help see what is going on. How clean is your Hera install? Maybe another app or ppa has changed something.

$ cat /usr/include/linux/stat.h | grep S_ISVTX
#define S_ISVTX  0001000

I did a pull within the afc-protocol branch to refresh contents, ran cd build; meson configure --clearcache; cd .., then meson build --prefix=/usr; cd build; ninja, and the error message is now this:

$ ninja
[10/125] Compiling C object 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o'.
FAILED: libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o 
cc -Ilibcore/342de7f@@pantheon-files-core@sha -Ilibcore -I../libcore -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/gee-0.8 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/granite -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -w -g '-DGETTEXT_PACKAGE="io.elementary.files"' -w -ggdb3 -O0 -std=c99 -Wall -Werror -fPIC -D_REENTRANT -pthread  -MD -MQ 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o' -MF 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o.d' -o 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o' -c 'libcore/342de7f@@pantheon-files-core@sha/File.c'
/home/dmayr/BUILD_AREA/io.elementary-files/libcore/File.vala: In function ‘gof_file_get_permissions_as_string’:
/home/dmayr/BUILD_AREA/io.elementary-files/libcore/File.vala:735:21: error: ‘S_ISVTX’ undeclared (first use in this function); did you mean ‘__S_ISVTX’?
         bool sticky = (permissions & Posix.S_ISVTX) != 0;
                     ^~~~~~~
                     __S_ISVTX
/home/dmayr/BUILD_AREA/io.elementary-files/libcore/File.vala:735:21: note: each undeclared identifier is reported only once for each function it appears in
[15/125] Compiling C object 'libcore/342de7f@@pantheon-files-core@sha/meson-generated_FileUtils.c.o'.
ninja: build stopped: subcommand failed.

If after building you look in the build directory, in the file:
files/build/libcore/342de7f@@pantheon-files-core@sha/FIle.c
you should find the lines:
#include <sys/stat.h>
and
sticky = (_tmp2_ & S_ISVTX) != ((guint32) 0);

If you find these then the Vala compiler is operating the same for both of us and the problem is presumably in the C compiler or its flags.

If I look in /build/ninja.build for the line that compiles File.c.o I get:

build libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o: c_COMPILER libcore/342de7f@@pantheon-files-core@sha/File.c || libcore/pantheon-files-core.h
 DEPFILE = libcore/342de7f@@pantheon-files-core@sha/meson-generated_File.c.o.d
 ARGS = -Ilibcore/342de7f@@pantheon-files-core@sha -Ilibcore -I../libcore -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/gee-0.8 -I/usr/include/at-spi2-atk/2.0 -I/usr/include/at-spi-2.0 -I/usr/include/dbus-1.0 -I/usr/lib/x86_64-linux-gnu/dbus-1.0/include -I/usr/include/gtk-3.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/granite -fdiagnostics-color=always -pipe -D_FILE_OFFSET_BITS=64 -w -g '-DGETTEXT_PACKAGE="io.elementary.files"' -w -fPIC -D_REENTRANT -pthread

You seem to have an extra flag -std=c99

According to this: https://stackoverflow.com/questions/28547271/s-ifmt-and-s-ifreg-undefined-with-std-c11-or-std-gnu11, setting this flag can cause the kind of error your have.

That was it; it compiled without errors!

Since I have to solve an exercise for a technical interview today, I'll install it tomorrow and test it extensively.
Thanks for the support and commitment to getting this quirk sorted out, I'll keep you posted!

Well, I've finally installed the afc-protocol branch of _Files_, first removing the pantheon-files package with apt (leaving the libpantheon-files-* libraries though).

The behavior remains unchanged.

What was experienced

_iPod_ as device: still recognized as a photo device under gphoto2://[usb:002,003]
_"iPod Documentation"_ mounts under afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb:3, where _iPod as a device_ would be expected under afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb (trailing :3 removed)

When accessing afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb (trailing :3 removed), _iPod_ appears as a network device, unrecognizable by media players such as _Rhythmbox_ or _Noise_.

Expected

_iPod_ recognized as _(local) device_ and mounted under afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb, where music players can see it.

@dennismayr Sorry for the slow response - and thank you for trying out the PR! Looks like I forgot to deal with the odd :3 suffix. I'll do that now.

I am not sure I can do anything about the gphoto2 protocol returned by one of the devices - that is an upstream issue - but I can make sure Files treats that protocol appropriately. I do not want to arbitrarily replace it by another protocol in the interface.

@dennismayr I have pushed some more commits to #1184 which, hopefully , improve things for you. I hope you will be able to give it a test.

I'll test it over the weekend!

Thanks for giving it another go

Update:

  • Mounting _local device_ iPod shows _DCIM_ folder (therefore, it's treated as a camera device)
  • Mounting _local device_ iPod Documentation mounts both _local device_ previously known as afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb:3 and afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb (_network device_ with trailing :3 removed) at the same time; the latter shows the correct directory structure that should've been mounted as _local device_ iPod
  • However, afc://028fd2b08554adf7c3aaf66e6ecb9af7d40daeeb is still shown as a _network device_, so music players like _Rhythmbox_ and _Noise_ can't access the iPod to manage media contents.

Therefore the problem, as you've suggested, may be related to the protocol backend.
This used to work well in previous Ubuntu versions, so it's likely to be an upstream issue.

@dennismayr Thanks for testing again! Now that the mounting problem is fixed, I'll fix the Sidebar category issue, which should be relatively straightforward.

Elementary OS has made me happy in many ways, so I'm glad to be of any help :smile:

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sprite-1 picture sprite-1  Â·  8Comments

apcamargo picture apcamargo  Â·  5Comments

micahilbery picture micahilbery  Â·  5Comments

a-tokarev picture a-tokarev  Â·  4Comments

CodingSpiderFox picture CodingSpiderFox  Â·  5Comments