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

[Thomas Järvstrand]

Please ignore the double negation in my previous email :)

file:path_open(["path1", "path2"], "foo/bar", SomeMode) should not fail
just because path1 happens to contain a regular file called foo.

T

On Fri, Oct 26, 2012 at 4:26 PM, Thomas Järvstrand <
thomas.jarvstrand@REDACTED> wrote:

> 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/18741a54/attachment.htm>