Odd behaviour of lfs.attributes and lfs.mkdir on Windows

[blasti]

Assume your are on Windows 7 with some HDD v:/. There is also a folder v:/rel.
Try this:

    print(lfs.attributes( "v:", "mode" ))
    print(lfs.attributes( "v://", "mode" ))
    print(lfs.attributes( "v:/", "mode" ))
    print(lfs.attributes( "v:/rel", "mode" ))
    print(lfs.attributes( "v:/rel/", "mode" ))
    print(lfs.attributes( "v:/rel//", "mode" ))
    print(lfs.mkdir("v:/s"))
    print(lfs.mkdir("v:/s/"))
    print(lfs.mkdir("v:/t/"))
    print(lfs.mkdir("v:/t"))

Result:

nil     cannot obtain information from file 'v:': No such file or directory
directory
directory
directory
nil     cannot obtain information from file 'v:/rel/': No such file or directory
nil     cannot obtain information from file 'v:/rel//': No such file or directory
true
nil     File exists
true
nil     File exists

So lfs.attributes does accept "/" at the end of a path, except it is the root directory.
Then you can even use "//".
But lfs.mkdir doesnt care at all.
Spend hours to find this bug in my code.
How is the situation on Linux? I didnt even try it yet.
Do I have to write a wrapper around each lfs function which expects a filepath, to find out what filepath does mean for each function and each platform?

[mpeterv]

stat() is bugged on Windows w.r.t. trailing slashes. Only lfs.attributes and lfs.symlinkattributes should be affected.

[blasti]

ok, i tried above stuff on Debian:

Lua 5.1.5  Copyright (C) 1994-2012 Lua.org, PUC-Rio
> l=require"lfs"
> return l.attributes("/", "mode")
directory
> return l.attributes("//", "mode")
directory
> return l.attributes("///", "mode")
directory
> return l.attributes("/bin", "mode")
directory
> return l.attributes("/bin/", "mode")
directory
> return l.mkdir "t"
true
> return l.mkdir "t/"
nil File exists
> return l.mkdir "u/"
true
> return l.mkdir "u"
nil File exists
> 

Looks much more sane here.