[erlang-bugs] file:path_open chokes on anything but enoent errors
Thomas Järvstrand
thomas.jarvstrand@REDACTED
Fri Oct 26 13:39:16 CEST 2012
Figured out what the error was and this is definitely a bug.
Steps to reproduce:
Create a "project" with the following tree
*
*
>
> * test-project $ tree*
> *.*
> *|-- include*
> *| `-- f.hrl*
> *`-- src*
> * `-- one.erl*
>
f.hrl:
> *-define(foo, foo).*
>
one.erl:
> *-module(one).
> -include("../include/f.hrl").
> one() -> ?hej.*
>
Now:
> * src $ cd test-project/
> test-project $ touch ../include
> test-project $ erl
> ...
> 1> c("src/one.erl").
> src/one.erl:2: can't find include file "../include/f.hrl"
> src/one.erl:3: undefined macro 'foo'
> error
> *
So, this fails because a component of the filename relative to cwd is not a
directory, whereas relative to the location of the source-file, it would be
a directory.
Thomas
On Fri, Oct 26, 2012 at 11:58 AM, Thomas Järvstrand <
thomas.jarvstrand@REDACTED> wrote:
> Hi!
>
> from the file-module:
>
>> *path_open_first([Path|Rest], Name, Mode, LastError) ->
>> case file_name(Path) of
>> {error, _} = Error ->
>> Error;
>> FilePath ->
>> FileName = fname_join(FilePath, Name),
>> case open(FileName, Mode) of
>> {ok, Fd} ->
>> {ok, Fd, FileName};
>> {error, enoent} ->
>> path_open_first(Rest, Name, Mode, LastError);
>> Error ->
>> Error
>> end
>> end;*
>>
>
> For some reason that I haven't deduced yet, my os seems to return enotdir
> instead of enoent when resolving a relative include. Compiling module with
> include-directives relative to the source in the shell will result in the
> call file:path_open([".",
> "path/to/src.erl"],"../../../relative/path/to/include", [read]), which
> fails because the second path in the list is never tried due to file:open/2
> returning enotdir.
>
> I have not yet figured out why I get this return value from the c-code,
> but shouldn't this be more permissive regardless? I feel that at in
> addition to enoent there should at least be support for eisdir and enotdir.
>
> Regards
> Thomas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121026/305dd6e5/attachment.htm>
More information about the erlang-bugs
mailing list