win32utils devel - Apr 2013 - win32-file-stat and unc directory paths

Hi everyone,

As I''m converting win32-file-stat to use FFI, I''ve run into an
issue where
I can''t seem to successfully call CreateFile on a UNC directory path.
It
works fine if I call it on a file, but not on the directory itself.

Using my own local network, this works:

# inside stat.rb
File::Stat.new("//myhost/users/djberge/documents/foo.txt")

But this does not:

File::Stat.new("//myhost/users")

Which is strange, because in a separate, standalone program it works fine,
but I can''t see what the difference is. I need a second pair of eyes,
please. The code is in git.

Thanks,

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/win32utils-devel/attachments/20130413/a6cd80ce/attachment.html>

Hi,

2013/4/13 Daniel Berger <djberg96 at gmail.com>:
> Hi everyone,
>
> As I''m converting win32-file-stat to use FFI, I''ve run
into an issue where I
> can''t seem to successfully call CreateFile on a UNC directory
path. It works
> fine if I call it on a file, but not on the directory itself.
>
> Using my own local network, this works:
>
> # inside stat.rb
> File::Stat.new("//myhost/users/djberge/documents/foo.txt")
>
> But this does not:
>
> File::Stat.new("//myhost/users")
>
> Which is strange, because in a separate, standalone program it works fine,
> but I can''t see what the difference is. I need a second pair of
eyes,
> please. The code is in git.
>
In my test, the latter case files in FindFirstFile instead of CreateFile:
The network name cannot be found. - FindFirstFile (SystemCallError)

I can see following statement in the msdn documentation of FindFirst:
On network shares, you can use an lpFileName in the form of the
following: "\\Server\Share\*". However, you cannot use an lpFileName
that points to the share itself; for example, "\\Server\Share" is not
valid.

I guess you will succeeds in case of
File::Stat.new("//myhost/users/djberge").

Regards,
Park Heesob

Ok, thanks. What a pain.

I''ve created a new branch called "ffi2". There I use
CreateFile +
GetFileInformationByHandle. That seems to work better for most cases, and
it can deal with UNC paths (both files and directories).

For special devices (pipes, etc) I have to resort to FindFirstFile, but
it''s not too bad.

Feel free to take a look and please let me know if there are any problems
with this approach.

Thanks,

Dan

PS - Stay safe over there Heesob. NK is acting a bit crazier than usual,
and has me worried.


On Sat, Apr 13, 2013 at 6:48 AM, Heesob Park <phasis at gmail.com> wrote:
> Hi,
>
> 2013/4/13 Daniel Berger <djberg96 at gmail.com>:
> > Hi everyone,
> >
> > As I''m converting win32-file-stat to use FFI, I''ve
run into an issue
> where I
> > can''t seem to successfully call CreateFile on a UNC directory
path. It
> works
> > fine if I call it on a file, but not on the directory itself.
> >
> > Using my own local network, this works:
> >
> > # inside stat.rb
> > File::Stat.new("//myhost/users/djberge/documents/foo.txt")
> >
> > But this does not:
> >
> > File::Stat.new("//myhost/users")
> >
> > Which is strange, because in a separate, standalone program it works
> fine,
> > but I can''t see what the difference is. I need a second pair
of eyes,
> > please. The code is in git.
> >
> In my test, the latter case files in FindFirstFile instead of CreateFile:
> The network name cannot be found. - FindFirstFile (SystemCallError)
>
> I can see following statement in the msdn documentation of FindFirst:
> On network shares, you can use an lpFileName in the form of the
> following: "\\Server\Share\*". However, you cannot use an
lpFileName
> that points to the share itself; for example, "\\Server\Share" is
not
> valid.
>
> I guess you will succeeds in case of
> File::Stat.new("//myhost/users/djberge").
>
> Regards,
> Park Heesob
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/win32utils-devel/attachments/20130413/d4fe9340/attachment.html>