VLC will not play files of External HDD Ubuntu 8.10

[Rémi Denis-Courmont]

in particular: no access_demux module matched "file" seems interesting...

Not at all:

[00000409] main demux warning: no access_demux module matched "file"
(...)
[00000410] main access debug: looking for access module: 3 candidates

The HFS+ filesystem accepts opendir() on a file. This is a bug in the file system driver, not in VLC.

[damian]

The HFS+ filesystem accepts opendir() on a file. This is a bug in the file system driver, not in VLC.

so VLC will remain unable to play files off HFS+ drivers until this filesystem-level bug is fixed? .. phrased this way it sounds like it should be considered a problem with VLC to me, actually, since the likelihood of a patch to fix VLC (ie not relying on the failure of opendir() to determine the difference between files and directories) is much higher than the likelihood of a patch to fix the filesystem (where any changes to the implementation of any kind of opendir() could break many many other things).

seeing as how opendir() is not ANSI standard, are you sure it's not a bug with the VLC specific implementation of opendir()? doing a find . -exec grep -hi opendir on the VLC source brings up a whole bunch of different definitions of opendir(), including something called utf8_opendir(), wopendir(), and at one stage (worryingly), #undef opendir().

[xtophe]

the man page of opendir() (see http://linux.die.net/man/3/opendir if you don't have on your system) indicate it is in POSIX
And there is an error code to indicate it is not a directory.


There is stuff around opendir in the code for OS with partial Posix support (read win32) and to convert from the VLC internal encoding (UTF-8) to whatever encoding the file system (claims to) uses.

[damian]

interesting. i'm on Debian (actually Ubuntu 8.10) and man opendir gives me 'no manual entry'.

but i'm convinced. when i get the chance i'll see if i can find a hack to fix this problem locally. in the meantime, have the relevant VLC devs (ie the people who know more specifics about the bug) posted a bug report to the hfsplus developers? _all_ of my movies are on HFS+ drives and mplayer isn't as good as VLC.

[damian]

so, in the absence of anyone on the VLC team doing so, i posted a bug report to the linux-fsdevel mailing list.

and they said the following: (http://marc.info/?l=linux-fsdevel&m=122825649904195&w=2)

From: Brad Boyer <flar@...>
To: Damian Stewart <damian@...>
Subject: Re: PROBLEM: hfsplus filesystem allows opendir() on plain files
Date: Tue, 2 Dec 2008 14:21:11 -0800
CC: <linux-fsdevel@vger.kernel.org>
On Tue, Dec 02, 2008 at 04:26:56PM +0100, Damian Stewart wrote:
> 1. hfsplus filesystem allows opendir() on plain files.
>
> 2. When opendir() is called on a plain file stored in an hfsplus
> filesystem, opendir() fails to return 0 and set errno to ENOTDIR.

Yes, this is a side effect of an intentional behavior. In osx, you
can open "file/rsrc" to get the resource fork of "file". This
behavior is emulated inside hfsplus on Linux, which means that to
some degree every file acts like a directory. There isn't a readdir
operation so it's not possible to list these, but it is possible to
do a lookup on this specific name. The code path taken by opendir
inside the kernel checks inode->i_op->lookup and returns ENOTDIR if
this function pointer is not set.

We can't fix this without either eliminating this way to open the
resource fork or making real changes to the generic Linux code. I'm
not sure what would be the appropriate thing to do in this case.
Someone on the mailing list is likely to have a strong opinion, so
there are likely to be suggestions of one sort or another.

Maybe the check in the generic code to decide what is a "directory"
should be changed? We could possibly check inode->i_fop->readdir.

Brad Boyer
flar@allandria.com

[Rémi Denis-Courmont]

Told you so - it's a kernel bug...

[ajstrobus]

Told you so - it's a kernel bug...

excuse the simpleness of my comment I obviously don't understand the coding level of this problem but,,

I'm terribly confused, if its a kernel bug / file system driver problem, why is it that every other video player i have plays the files perfectly & vlc doesn't, is it the way vlc access's files thats different than xine or mplayer? I just think its weird that the filesystem bug doesn't affect those players at all, only vlc 0.9.4 in ubuntu 8.10. I must be missing something...

Its just that I've always stood by vlc & to see mplayer & xine effortlessly play something that vlc can't is a first for me, its always been my "Play anything player" & now its the only one I have that can't play my .avi's.

[ajstrobus]

z-oh My Gooosh... I LOVE VLC NOW IT WORKS! ----> VLC PLAYS AVI's FROM THE HFS+ EXTERNAL DRIVE!! Here's how to revert to 0.8.6 & play your files from HFS+: (these work on 64bit intrepid, if you have 32 download the 32 version of the 3 files)

1.) uninstall vlc & dependencies from synaptic package manager

2.)download & install http://launchpadlibrarian.net/15988560/ ... _amd64.deb

3.)download & install http://launchpadlibrarian.net/15988559/ ... _amd64.deb

4.)download & install http://launchpadlibrarian.net/15988558/ ... _amd64.deb

install in that order & Gdebi package installer will automatically download a few more dependencies. Right after install VLC OPENED MY .avi's that 0.9.4 NEVER WOULD on HFS+ EXTERNAL DRIVE!!!! I wish the site admin would have posted this simple work around to install 0.8.6 a month ago.....

[damian]

I'm terribly confused, if its a kernel bug / file system driver problem, why is it that every other video player i have plays the files perfectly & vlc doesn't, is it the way vlc access's files thats different than xine or mplayer? I just think its weird that the filesystem bug doesn't affect those players at all, only vlc 0.9.4 in ubuntu 8.10. I must be missing something...

it's like this: VLC will let you pass in either a single file or an entire folder to play movies out of. this means that they have to have some way of detecting whether or not the string you've given them (eg "/home/username/Movies/movie.avi" or "/home/username/Movies") is a directory or a plain file.

the way they are doing it is not really the most reliable - it relies on a byproduct of a particular operation: they try to blindly open the file as a 'directory' by calling opendir(), and if that fails, they assume it's not a directory and so open it as a plain file. the problem is that because of the way the HFS+ filesystem works (it has 'resource' forks and 'data' forks for each file), the opendir() call _doesn't_ fail for plain files, and so VLC thinks all files are directories. a more robust (ie better) way to do the detection would be to call stat() on the file and then read the info structure it returns, which would tell them explicitly whether it was a file or a directory, but they're not doing this. when i get a chance i might fix it so it is doing this and submit a patch.

in the meantime i'm very unimpressed with the blunt dismissiveness of the devs who've posted here so far. but, well, that's open source for you, isn't it.

[Rémi Denis-Courmont]

it's like this: VLC will let you pass in either a single file or an entire folder to play movies out of. this means that they have to have some way of detecting whether or not the string you've given them (eg "/home/username/Movies/movie.avi" or "/home/username/Movies") is a directory or a plain file.

the way they are doing it is not really the most reliable - it relies on a byproduct of a particular operation: they try to blindly open the file as a 'directory' by calling opendir(), and if that fails, they assume it's not a directory and so open it as a plain file.

I completely disagree here. stat() is prone to race conditions, and means we would lookup paths twice as many times (and we already look them up quite a few times when probing). By POSIX, the VLC operations is 100% reliable:

The opendir() function will fail if:
(...)
[ENOTDIR]
A component of dirname is not a directory.

The HFS+ driver has a horrible bug. The blame is entirely on the HFS+ driver. And the way VLC operate is good. Full point.

We are not going to "fix" this.

[simonnix]

Hi everyone.

I must complain about this situation. It's been two months now and nothing from the kernel devs and VLC devs have been done to resolve this issue.

On one side we have the VLC devs (I love you guys, you're so handsome and great and I so admire you. It's my inside fan girl speaking, sorry) who says "Euh I am sorry, we are 100% POSIX compliant, so if POSIX don't work all the time it's everyone else fault". On the other end we have the kernel gurus (long beard, greasy hair, not as sexy but still so cool) saying "Damn we have this bug and we could fix it but it's involve so many other stuff to change and we don't have time to do that and we don't maintain that piece of code anymore but we are not sure and it's a feature etc...".

So it's nobody problem, nobody cares about that. At the end of the day VLC is still not able to read files from HFS+ filesystems in Linux.

Let say Microsoft Windows were doing non standard things regarding their documentation like say in their file server protocol or API, what should the Wine and Samba projects do? Stay right on the paper and let their users not able to do things like Windows do or try to imitate and workaround those limitations? Hey it's Microsoft problem, right?

And now if some API that VLC use in Windows does not work like documented, what a VLC dev should do? Workaround those limitations, bugs or features (as stated by someone) and let their users actually play some files or stay on course with this right on paper documentation???

So, and I am not a developer guru, imagining that for a second the VLC devs care about their users and what they want and want to make them happy by letting them play their files, could it be possible that before you make your opendir() call for a specific file:// URL you check for the filesystem in which it reside and use opendir or stat depending on the situation. Because, frankly, I really don't care about a race condition right now.

Between VLC that may block after a stat() and just opening and doing nothing I prefer the maybe a block.

So can we imagine a patch with maybe some comment like

# Horrible hack that let our users play files on HFS+
# Until the Linux kernel is fixed

no???

[Jean-Baptiste Kempf]

can you try to cat file and pipe it to vlc ?

[Rémi Denis-Courmont]

Between VLC that may block after a stat() and just opening and doing nothing I prefer the maybe a block.

I am not going to purposedly add a bug that would freeze the player in the normal case (including Linux on any filesystem other than HFS+).

[simonnix]

I have been a long time VLC user. For more than 10 years now, back in the BeOS days, before it became the most used video player.

First the Qt GUI rewrite which make my daily experience with VLC not as good as it used to and now this "hability" to play a directory which does not work for me on my shared drive between Mac OS X and Linux.

For now on I will still recommand your player to my Windows friends, but for me personnally you have definetly jumped the shark. You're trying to do too much and fail.

Sincerely.