GNOME Bugzilla – Bug 627362
Should detect ahead of time if the partition mounted for the DAP device has read-only access for the current user
Last modified: 2020-03-17 08:52:56 UTC
Somehow it hcan happen that the system mounts your device as read-only (a `ls -lha` on it reveals all files are root/root 755), then the consequence of the synchronization process of Banshee is obviously this: [9 Warn 15:06:01.403] Failed to save iPod database - System.UnauthorizedAccessException: Access to the path "/media/KNOCPOD_/iPod_Control/iTunes/iTunesDB" or "/media/KNOCPOD_/iPod_Control/iTunes/iTunesDB.bak" is denied. (in `mscorlib') at System.IO.File.Copy (System.String sourceFileName, System.String destFileName, Boolean overwrite) [0x001c5] in /usr/src/packages/BUILD/mono-2.6.3/mcs/class/corlib/System.IO/File.cs:126 at IPod.TrackDatabase.Save () [0x00125] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/TrackDatabase.cs:2718 at IPod.Device.Save () [0x0000b] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/Device.cs:282 at Banshee.Dap.Ipod.IpodSource.PerformSyncThreadCycle () [0x00313] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:634 We should detect this situation ahead of time, cancel any sync capabilities/operations and inform the user about it.
Other stacktraces for the sameproblem: [8 Warn 16:15:05.181] Failed to create iPod track with Uri file:///home/knocte/Documents/Musica/mp3/Varios/Idylic/Zoot%20Woman%20-%20Lonely%20By%20Your%20Side.mp3 - System.UnauthorizedAccessException: Access to the path "/media/KNOCPOD/iPod_Control/Music/F27/" is denied. (in `mscorlib') at System.IO.Directory.CreateDirectoriesInternal (System.String path) [0x0006e] in /usr/src/packages/BUILD/mono-2.6.3/mcs/class/corlib/System.IO/Directory.cs:133 at System.IO.Directory.CreateDirectory (System.String path) [0x0009a] in /usr/src/packages/BUILD/mono-2.6.3/mcs/class/corlib/System.IO/Directory.cs:94 at IPod.TrackDatabase.MakeUniquePodTrackPath (System.String filename) [0x00056] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/TrackDatabase.cs:2583 at IPod.TrackDatabase.GetUniquePodPath (System.String path) [0x00008] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/TrackDatabase.cs:2863 at IPod.Track.set_Uri (System.Uri value) [0x00088] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/Track.cs:105 at IPod.Track.set_FileName (System.String value) [0x00000] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/Track.cs:77 at IPod.TrackDatabase.CreateTrack (System.String filename) [0x00007] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/TrackDatabase.cs:2964 at Banshee.Dap.Ipod.IpodTrackInfo.CommitToIpod (IPod.Device device) [0x00013] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodTrackInfo.cs:195 [8 Warn 16:15:05.203] Caught an exception - System.NullReferenceException: Object reference not set to an instance of an object (in `ipod-sharp') at IPod.Playlist.InsertTrack (Int32 index, IPod.Track track) [0x00016] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/Playlist.cs:88 at IPod.Playlist.AddTrack (IPod.Track track) [0x00000] in /usr/src/packages/BUILD/ipod-sharp-0.8.5/src/Playlist.cs:102 at Banshee.Dap.Ipod.IpodSource.PerformSyncThreadCycle () [0x00260] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:621 at Banshee.Dap.Ipod.IpodSource.PerformSyncThread () [0x0001c] in /home/knocte/Documentos/banshee/src/Dap/Banshee.Dap.Ipod/Banshee.Dap.Ipod/IpodSource.cs:546
Today I had banshee frozen when I connected my iPod. The debug log said at the end: [5 Debug 11:50:59.817] Found DAP support (Banshee.Dap.Ipod.IpodSource) for device KNOCPOD and Uuid /org/freedesktop/Hal/devices/volume_uuid_30E9_5C54 libusb couldn't open USB device /dev/bus/usb/001/009: Permission denied. libusb requires write access to USB device nodes. libusb couldn't open USB device /dev/bus/usb/001/006: Permission denied. libusb requires write access to USB device nodes. [6 Debug 11:51:00.399] Starting - Sincronizando iPod libusb couldn't open USB device /dev/bus/usb/001/009: Permission denied. libusb requires write access to USB device nodes. libusb couldn't open USB device /dev/bus/usb/001/006: Permission denied. libusb requires write access to USB device nodes. However, I can certify that this time the device was not mounted as read-only, so this is weird.
There is a DapSource (or RemovableSource) property for ReadOnly that must not be getting set properly. When it's true, sync should be disabled.
(In reply to comment #3) > There is a DapSource (or RemovableSource) property for ReadOnly that must not > be getting set properly. When it's true, sync should be disabled. I see! I am only able to reproduce this occassionally (only when I get the device mounted as readonly by no apparent reason). I'm right now reproducing it and the ReadOnly property maps to the ReadOnly property of the volume, which maps to this in Banshee.Hal/Banshee.HalBackend/Volume.cs: public bool IsReadOnly { get { return (dk_disk != null && dk_disk.IsReadOnly) || HalDevice.GetPropertyBoolean ("volume.is_mounted_read_only"); } } I've put CWLs there and all of those clauses are returning FALSE! That is: dk_disk != null -> true dk_disk.IsReadOnly -> false HalDevice.GetPropertyBoolean ("volume.is_mounted_read_only"); -> false Any tips how I should debug this further Gabriel?
Created attachment 169665 [details] log of python+dbus testing (In reply to comment #4) > dk_disk.IsReadOnly -> false > > Any tips how I should debug this further Gabriel? To verify the above is true, I used some guidelines from [1] to query dbus myself, and this is the result. So, unless I'm misinterpreting what "0" means in python, is this a bug of DeviceKit? [1] http://moserei.de/index.php/179/accessing-devicekit-with-dbus-and-python
The output of the command `haldevice` also outputs the property "volume.is_mounted_read_only" as "=false" so I guess this is a bug somewhere in my underlying system (hal, devicekit, kernel? you name it). I guess I should close this as NOTGNOME?
(In reply to comment #6) > I guess I should close this as NOTGNOME? Or other option is to implement a workaround for this bug, trying to create and remove a dummy file in the device. Thoughts?
Aha!!! Just found out what happens, it's not that the device is mounted as read-only (so there was no such bug in DeviceKit/HAL/younameit), but that somehow sometimes when I connect the device, the folder is mounted with root-only access. So I can modify the contents of it using sudo but not without it! Any feedback on how to detect this situation from within Banshee is appreciated.
Created attachment 169715 [details] [review] Patch for Ipod extension This patch fixes the problem for me. It targets the iPod extension. I'll post ASAP another one for the AppleDevice extension.
Created attachment 170234 [details] [review] Patch v2 (In reply to comment #9) > This patch fixes the problem for me. It targets the iPod extension. I'll post > ASAP another one for the AppleDevice extension. I've realised that both patches would share a common method, so I'm posting a new patch which targets both teh iPod and AppleDevice extensions.
Review of attachment 170234 [details] [review]: Looks good to me as long as no-one has any issues adding the method to HardwareManager.
Banshee is not under active development anymore and had its last code changes more than three years ago. Its codebase has been archived. Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is being shut down) if anyone takes the responsibility for active development again. See https://gitlab.gnome.org/Infrastructure/Infrastructure/issues/264 for more info.