UNC path and folderitem

Targets Windows
1

Hi,

I’m having some troubles with Windows UNC folderpaths using as folderitem.
I found an old forumtopic (in the old Realbasic forum) about troubles with UNC filepaths and folderitem.exists and .isWriteable.
I hope that now five years later these problems are solved but I still can’t use UNC filespaths.

What am I doing wrong, or is this still an issue and is there a good workaround:

This doesn’t work:

[code]
'gfldData is a folderitem global in my application.

dim strFolder as string
strFolder = “\\LG-NAS-MVB\Backup”
gfldData = GetFolderItem (strFolder, FolderItem.PathTypeNative)

if gflddata <> nil and gfldData.Exists = true then
msgbox “Yes it works”
else
msgbox “No, it doesn’t work” 'I always end up here!
end if[/code]

Best regards,
Marc

2

Marc…

I recently ran into the same problem… It seems that the .exists (and possibly other properties) are not updated properly… but I was still able to open, write to and close the folderitem…

So instead of using .exists, I wrapped the code I needed to use on the folderitem in a Try to catch errors.

1 Like
3

Did you file a bug report about this?

4

Not yet…

5

I experienced similar problems.
And I believe a bug report exists somewhere in space and time… will try to find it.

6

i found this issue in feedback. It seems this is the bug to be fixed as soon as possible.
<https://xojo.com/issue/22987>

7

[quote=152564:@Marc van Buel]i found this issue in feedback. It seems this is the bug to be fixed as soon as possible.
<https://xojo.com/issue/22987>[/quote]

Exactly! Nice job Marc.

Now, what about a fix? :stuck_out_tongue:

8

We ran into this as well, but from a different situation.

We noticed that a Xojo Application running on Windows 8.1 had a “delay” of up to 20 seconds compared to the very same app running on Windows 7. This “idle waiting time” has been tracked down to the following call: (FolderItem).Exists, where (FolderItem) is referring to a Network-Share (the “root” of the Network share).

Digging deeper reveals:

Dim oFolderItem As FolderItem = GetFolderItem("\\\\myserver\\myshare", FolderItem.PathTypeAbsolute) if oFolderItem.Exists then
The Xojo-Framework checks if \\myserver\myshar exists.
→ Note: the last character of the Path has been cut by the framework for this call to check .Exists
You can check this yourself: Process Monitor The steps are described in my Feedback Report.

This is the reason why FolderITem.Exists returns “false” instead of “true” (in the case where the UNC-Path is pointing to an existing root of a Network Share).
On Windows 7, the only issue is that FolderItem.Exists reports false (instead of true)
However, on Windows 8.1, this can cause a “network lookup delay” of up to 20 seconds!

Sure, the “delay” can be considered a Bug of Windows 8.1. But the cause of this happening in a Xojo Application is that FolderItem.Exists queries a wrong path.

I reported this as a new Feedback Issue: <https://xojo.com/issue/38665> (and requested the other reports to be merged in: <https://xojo.com/issue/7319> and <https://xojo.com/issue/22987>)

@Massimo Valle - I provided a Workaround for this issue (see the example project attached to my Feedback report):
Windows - Dev Center
On Windows (and Desktop), first check yourself: if (PathIsUNCServerShare AND PathIsRoot AND PathFileExists) then… this is an existing and valid/existing UNC-Path to the root of a Network Share.
(of course, you should clean up the example-code in the workaround, so that it works as a replacement for FolderItem.Exists and refactor it to a “Extends FolderItem”).

This issue affects also other Properties of FolderItem. If you inspect such a FolderItem (with UNC-Path to the root of a Network Share), you’ll see a lot of calls to the wrong (last character cut) path. So other on-access-Properties of FolderItem are affected by probably the same FolderItem-internal/Framework-issue.

This issue with FolderItem cutting the last character seems to be only happening to UNC-Paths referring to a Network Share. No issues with UNC-Path to a folder inside a Network Share. And of course no issue if you mount the NetworkShare and assign a Drive Letter.

9

Bump – was this ever fixed? I’m running into essentially the same issue with UNC paths on Windows Server 2012r2.

If I try to use a path like this:

Dim f as FolderItem = GetFolderItem("\\\\123.456.789.000\\foo\\bar", FolderItem.PathTypeNative)

If I check f.Exists, it’s always false even though the folder is there. If I bypass the f.Exists check, the app fails when I try to do this:

Dim f2 as FolderItem = f.Child("hello world") f2.CreateAsFolder
Any suggestions for workarounds? Xojo seems not to like UNC paths at all.

Running Xojo 2017r3 - tried compiling on both Mac 10.12.6 and Windows Server 2012r2 just in case there were any differences.

Thanks!

10

Try

Dim sh As New Shell sh.Execute("NET USE \\\\123.456.789.000\\foo") Dim f as FolderItem = GetFolderItem("\\\\123.456.789.000\\foo\\bar", FolderItem.PathTypeNative)
and see how that works.

11

Thanks @Wayne Golding, but I now think the problem is somewhere else.

The console app is installed as a service, and is running as such when it fails to get the folderItem.

If I install the whole Xojo environment on the server, and run the console app in Debug mode, it all works perfectly.

Which makes me think that this is some kind of permissions problem. Except that the service is set to logon as Administrator (i.e. the same account I’m using when I run the app in Xojo on the desktop) – so permissions should be the same, no?

12

You could try debugging the app while the debug article is running as a service. See https://youtu.be/QV_2mc3uvaw

13

[quote=368125:@Charles Weger]Thanks @Wayne Golding, but I now think the problem is somewhere else.

The console app is installed as a service, and is running as such when it fails to get the folderItem.

If I install the whole Xojo environment on the server, and run the console app in Debug mode, it all works perfectly.

Which makes me think that this is some kind of permissions problem. Except that the service is set to logon as Administrator (i.e. the same account I’m using when I run the app in Xojo on the desktop) – so permissions should be the same, no?[/quote]

FYI. From a security point of view I wouldn’t run the service as Administrator.

The problem you are possibly having is that the service does not have permission to access the UNC share. Services don’t run in the same environment as a GUI login.
I don’t have a full list of steps but this is a summary of what we do:

  1. Create a new user for the service making sure it has network access.
  2. Make sure the user has permissions to the relevant directories on the local disk (ie: where the service is installed).
  3. Assign the user to the service.
  4. Login to the service user.
  5. Store the credentials for the UNC path you want to access (I think you do this via the Credentials Manager in the latest versions of Windows).
  6. Logout of the service user and log back in as the administrator.
  7. Start the service.

NOTE. After step 5 you should be able to test if the credentials have been stored correctly by typing the UNC path into the Windows Explorer. If you are automatically logged in then the stored credentials are working. If you are asked to login then you have done something wrong.

14

Thanks @Kevin Gale for the advice. I know that services shouldn’t run as Administrator, but it was the simplest way to test. The Administrator account can definitely access the share, because I can type the UNC path into an Explorer window. To make things even simpler, I am now testing with a UNC path on the same machine, to avoid possible network issues.

The very odd thing about all of this is that an earlier version of the app that’s having problems is running just fine on another Windows Server; however this earlier version was built with Xojo 2017r1.1. For various reasons it’s difficult to go back to that development environment, but now I’m thinking we should try because perhaps this an issue with 2017r3.

More details as they develop. Thanks.

15

Does it also work on the server you’re having problems with?

16

That’s complicated. Both of these servers are in production, so I can’t just switch software configurations without a lot of paperwork and permissions. Plus, as a vendor I’m not allowed to actually touch the servers, which means I have to WebEx in and talk an IT person through the changes I want to make. Very painful.

17

Doh, that’s a pain.

Here’s some (messy) code to test a few things, see how you get on.

https://www.dropbox.com/s/c2y9ds2wqc9grbo/NetworkConnection.xojo_binary_project?dl=1

The calls to PathFileExists and GetFileAttributes will at least give you a human readable error message to let you know what the problem is. This will probably give you a insight into whats going wrong.

Xojo probably use these calls inside the framework, I don’t know which though. I’m guessing PathFileExists (due to the historic problems with getting info on network share from previous posts above), but they might have moved to GetFileAttributes recently which is why there might be a different result with different versions of Xojo. I know they were trying to speed up FolderItems a little while back (or maybe I dreamt that).

Try clicking “check” before you click open to see if things work out of the box.

You might need to click connect more than once as it’ll randomly return error 53 for some reason (not figured that out yet, only found one reference to it, people probably just try a few times).

Upon closing the connection it will remain active for a little while (not timed it, probably, 30-60 seconds) while things are disconnected, MS probably put that in to stop reconnect spam issues on large networks.

It’s all worked as expected on my lan here, connecting from Win10 to different Server 2012r2 boxes, shares, folders and files.

If they are running anything under Win 8 or Server 2012 then that will change how much of this works:

See Remarks on GetFileAttributes “If you call GetFileAttributes for a network share, the function fails, and GetLastError returns ERROR_BAD_NETPATH. You must specify a path to a subfolder on that share.” “In Windows 8 and Windows Server 2012, this function is supported by the following technologies.”

You might also want to check your username, you might need to specify “DOMAIN\administrator” as your username if they disable local admin in preference of domain admin.