Filecopy and UNC-pathname

  • Thread starter Thread starter Jos Vens
  • Start date Start date
J

Jos Vens

Hi,

I discovered that it is not possible to use the FileCopy statement in
junction with a UNC pathname.

eg. FileCopy "C:\TEMP\Test.xls", "F:\LibraData\Test.xls" works fine
FileCopy "C:\TEMP\Test.xls", "\\Acer01\LibraData\Test.xls" don't works. I
get the error message: 75 cannot access... however, LibraData is shared on
my computer with the name Acer01.

How can I solve this (I don't know on which drive the user has placed his
data). Is it possible to get the local pathname out of the shared UNC
pathname (so that \\Acer01\ is translated to eg. F:\) or is there an
alternative for the FileCopy statement?

Thanks
Jos Vens
 
Jos,

I am confused. I assume that F is the local mapped drive letter? If so, why
are you using the UNC, why not just use the mapped drive letter?

As to the question, Randy Birch shows how to enumerate local network
resources, but this takes a lot of code, and maybe is overkill for you.

--

HTH

Bob Phillips
... looking out across Poole Harbour to the Purbecks
(remove nothere from the email address if mailing direct)
 
Hi Bob,

F is the logical drive (partition of my harddisk), not a mapped drive.
Maybe there is a solution to use a mapped drive letter in stead of a
UNC-path.

The reason for using a unc-path is that it can be perfectly done within VBA
(with an API-call - if it is possible to make a mapped drive in VBA, it's ok
for me) and the user can put the data whereever he wants, the program (which
is in C:\Program Files) is an addin (.xla) and finds the data, even over the
network.

However, copying new data to the user's datafolder (with UNC - it's the
destination folder that must be with a drive letter, not \\) gives an error
message.

Can you help me further?

Thanks
Jos Vens
 
I have found the same need. There is somewhat of a work around. You can
create a hyperlink in a workbook (either manually or by VBA) that uses a
UNC. Then you can follow that hyperlink from within VBA using
Selection.Hyperlinks(1).Follow NewWindow:=False, AddHistory:=True.

Tom
 
Hi Tom,

nice try, but I think it doesn't bring me any further: the folow method is a
sub, not a function, so it gives me no result. I tried this

In my workbook, I write the UNC-pathname in the activecell. Then in the
command window I do this:

Selection.Hyperlinks(1).Follow NewWindow:=False, AddHistory:=True
?activeworkbook.FullName
\\Acer01\LibraData\Data\0304\Versie.xls

So I thought, let me open a workbook on that place and look for the
pathname, but it is also UNC!

Can anyone help or am I missing something of your explanation? Let's repeat
my question: I want to copy a file from folder1 to folder2, but the path of
folder2 is an UNC-path (folder1 to but thats no problem for the procedure)

FileCopy \\Computer\Folder1\File.xls, \\Computer\Folder2\File.xls

If I replace \\Computer\Folder2\File.xls with C:\Folder2\File.xls,
everything works fine. However, I don't know where my customer has placed
Folder2, I certainly do know the shared name.

Thanks
Jos
 
Hi Jos,

I don't believe filecopy works with UNC paths.
You can map the UNC path to a drive letter on the fly with MyDrive=shell (net use...)
Then you can do...
FileCopy "C:\TEMP\Test.xls", MyDrive & "\Test.xls"

And it would be nice to have the option to kill the mapping on exit.


See some other info here. http://www.google.com/groups?hl=en&...20and&safe=images&ie=UTF-8&oe=UTF-8&lr=&hl=en

As far as not knowing what drive the user is using for the data, make them browse to the folder and store it as a variable.

--
John
johnf 202 at hotmail dot com


| Hi,
|
| I discovered that it is not possible to use the FileCopy statement in
| junction with a UNC pathname.
|
| eg. FileCopy "C:\TEMP\Test.xls", "F:\LibraData\Test.xls" works fine
| FileCopy "C:\TEMP\Test.xls", "\\Acer01\LibraData\Test.xls" don't works. I
| get the error message: 75 cannot access... however, LibraData is shared on
| my computer with the name Acer01.
|
| How can I solve this (I don't know on which drive the user has placed his
| data). Is it possible to get the local pathname out of the shared UNC
| pathname (so that \\Acer01\ is translated to eg. F:\) or is there an
| alternative for the FileCopy statement?
|
| Thanks
| Jos Vens
|
|
 
Hi John,

I tried this but it doesn't work! The problem is that the path of the
mapped drive eg. Q is \\Acer01\Folder2\ (I only know the UNC-path). If I
Filecopy to Q, I get the same error message as if I should copy directly to
the UNC-path.

It's a nice suggestion with net use. I suppose you can kill the mapping
with net use Q without a path.

Thanks anyway
Jos

"jaf" <[email protected]> schreef in bericht
Hi Jos,

I don't believe filecopy works with UNC paths.
You can map the UNC path to a drive letter on the fly with MyDrive=shell
(net use...)
Then you can do...
FileCopy "C:\TEMP\Test.xls", MyDrive & "\Test.xls"

And it would be nice to have the option to kill the mapping on exit.


See some other info here.
http://www.google.com/groups?hl=en&...20and&safe=images&ie=UTF-8&oe=UTF-8&lr=&hl=en

As far as not knowing what drive the user is using for the data, make them
browse to the folder and store it as a variable.

--
John
johnf 202 at hotmail dot com


| Hi,
|
| I discovered that it is not possible to use the FileCopy statement in
| junction with a UNC pathname.
|
| eg. FileCopy "C:\TEMP\Test.xls", "F:\LibraData\Test.xls" works fine
| FileCopy "C:\TEMP\Test.xls", "\\Acer01\LibraData\Test.xls" don't works. I
| get the error message: 75 cannot access... however, LibraData is shared on
| my computer with the name Acer01.
|
| How can I solve this (I don't know on which drive the user has placed his
| data). Is it possible to get the local pathname out of the shared UNC
| pathname (so that \\Acer01\ is translated to eg. F:\) or is there an
| alternative for the FileCopy statement?
|
| Thanks
| Jos Vens
|
|
 
Shame on me!!!

Filecopy does work with UNC-path's but my shared folder gave me not enough
rights to write to that folder (there are 2 types of rights: the user rights
and the share rights) It were the latter that troubled my view...

Sorry for the problem and thanks for all who gave the best of theirselves!

Jos
 
Back
Top