| Summary: | "unable to open file" on mounted smbfs shares. permissions correct. | ||
|---|---|---|---|
| Product: | [Frameworks and Libraries] taglib | Reporter: | Richard Edmands <dmz> |
| Component: | general | Assignee: | Scott Wheeler <wheeler> |
| Status: | RESOLVED NOT A BUG | ||
| Severity: | normal | CC: | ch75, haplo81, ich, jeff.mitchell, serzholino |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | openSUSE | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Attachments: |
amarok file
patch to retry failed r/w fopen r/o |
||
|
Description
Richard Edmands
2005-07-22 08:57:46 UTC
Can you see if you're able to read the metadata for them in Konqueror? (right click on the file -> properties -> meta data) Which other media players are able to read the files? Scott Wheeler wrote: [bugs.kde.org quoted mail] konqueror: no meta data tab or button or whatever, depending on however konqueror was supposed to handle that xmms: works, right clicking on files in the playlist and going view info brings up the ID3 tags happily. xine: (from memory) happy to play, donno about the tags tho. mplayer: happy to play, donno about the tags tho. amaroK: happy to play, but won't add files to the "collection". During attempts, the terminal spits out taglib: can't open file /home/user/music/***.mp3 And you are able to read these files if you copy them to another partition? Which kernel version? There were bugs in the smbfs code in all but the most recent Linux kernels, so you may be hitting them. It would be interesting to test a non-KDE taglib app. yeah, if i copy the files to locally, they are perfectly happy in every tested way. uname -a spits out : Linux linux 2.6.11.4-21.7-default #1 Thu Jun 2 14:23:14 UTC 2005 i686 i686 i386 GNU/Linux is that recent enough? I've talked with Scott last night and we don't think it's the old smbfs bug. However, given that it doesn't work in smb mounts only, we're at loss. We don't believe it's a taglib bug, though. Can you run this: strace -f -o /tmp/amarok amarokapp then try to open one such file, then close amarok? Attach the produced file here, please (or mail it to one of us, if you don't want your information disclosed). Created attachment 11918 [details]
amarok file
looks like my last attempt to reply got interperated funny by something. well,
i'm doing this manually now, the file is compressed this time to save space.
"yeah, i had a read of the file /tmp/amarok when it gets to the part about the
mp3's, it says crap about permission denied, which seems illogical, cause, read
and execute permissions are fine... unless it's trying to write, which would be
completely inappropriate and concerning.
File is about 1.8MB
md5: 8ad6532617c5be333427e15d60c031e1"
Ok, this is a file system bug. The interesting line is the one before "permission denied". When TagLib opens a file it first checks to see if the file is writable. If it is it opens it in read/write mode; if not it opens it in read only mode. The problem is that your file system is reporting that it's writable, then TagLib tries to open it in read read/write mode and gets permission denied. If the check to see if it is writable were correctly returning false, then it would open the file in read only mode. *** Bug 102281 has been marked as a duplicate of this bug. *** Scott-- Have you reported this to the samba folk? Thanks. No, I haven't. Someone told me that it's fixed in the most recent version, but I haven't confirmed that. meh, i'll test it, which distro would have the version of samba i should be testing? Gentoo, circa March 23rd 2005? :-) I can test it too with Gentoo current. Just for future reference: https://bugzilla.samba.org/show_bug.cgi?id=3088#c5 Scott Wheeler wrote: [bugs.kde.org quoted mail] yeah, i reported the bug, it was temporary fixed by adding -r to the command, someone said something about it being fixed in a new version of something, so i was going to test it. dam i hate short-term memory. *** Bug 117977 has been marked as a duplicate of this bug. *** Created attachment 18028 [details]
patch to retry failed r/w fopen r/o
The cifs file system implementation could probably do something about the issue
of read-only exported shares mounted read-write. But then, the check for
writability is ultimately done on the server, but access(2) does not involve
the server.
The same problem might happen with nfs mounts. The RESTRICTIONS section of my
Linux access(2) man page contains this:
---
access() may not work correctly on NFS file systems with UID mapping enabled,
because UID mapping is done on the server and hidden from the client, which
checks permissions.
---
So I suggest to implement something like the work-around in the attached patch.
*** Bug 98771 has been marked as a duplicate of this bug. *** *** Bug 135243 has been marked as a duplicate of this bug. *** |