[erlang-bugs] file:path_open chokes on anything but enoent errors

[Thomas Järvstrand]

Well, the correctness of the include-directive can definitely be
questioned, I didn't write it, I was just the one who ran into a problem
with it :P

Regardless, in the general case I don't think that file:path_open(["path1",
"path2"], "foo/bar", SomeMode) should not fail just because path1 happens
to contain a regular file called foo.

Thomas

On Fri, Oct 26, 2012 at 3:17 PM, Alexander Harju <
alexander.harju@REDACTED> wrote:

> I don't think this is a bug at all.
> -include(...) should not contain a path.
> Use compile:file("one.erl", [{i, Dir},...])
>
> // Alex
>
> On Fri, Oct 26, 2012 at 1:39 PM, Thomas Järvstrand <
> thomas.jarvstrand@REDACTED> wrote:
>
>> 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
>>>
>>
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://erlang.org/mailman/listinfo/erlang-bugs
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20121026/efbe9b67/attachment.htm>