Strip Path on network path can crash LV

[Francois Normandin]

Just reporting a bug I stumbled on recently.

The problem comes when you want to strip a network path that looks like this "\\server\dir\subdir".

When stripping the path with the "Strip Path" primitive, it would correctly output "\\server\dir" for the stripped path and "subdir" for name.

Doing it a second time should return "\\server" for stripped path and "\dir" for name.

Instead, you get an empty stripped path and the input is copied to name output (Incorrect results). Furthermore, if the stripped path output is wired, it will most likely crash LabVIEW. The current workaround is to assign a drive letter to the network path using "Map Network Drive" in Windows. (Dunno for other OS) It works fine with path that start with "X:\"

This has been tested with LV2009 on 32-bit system (WinXP).

[asbo]

This has been tested with LV2009 on 32-bit system (WinXP).

This presents the same way in 8.5 and 8.6. In 8.0 and 8.2, you'll actually get nothing for "name 2" and <Not a Path> for the stripped path. (all WinXP 32-bit)

Another weird thing I noticed: when setting a path constant to "\\server\dir\subdir" on the BD, LabVIEW will hang for a bit after you remove focus/press ENTER - apparently it tries to verify path constants right away. Learn something new every day.

[Francois Normandin]

This presents the same way in 8.5 and 8.6. In 8.0 and 8.2, you'll actually get nothing for "name 2" and <Not a Path> for the stripped path. (all WinXP 32-bit)

Another weird thing I noticed: when setting a path constant to "\\server\dir\subdir" on the BD, LabVIEW will hang for a bit after you remove focus/press ENTER - apparently it tries to verify path constants right away. Learn something new every day.

Indeed.

It also affects the OpenG VIs, since it relies on the Strip Path primitive.

[Rolf Kalbermatter]

Just reporting a bug I stumbled on recently.

The problem comes when you want to strip a network path that looks like this "\\server\dir\subdir".

When stripping the path with the "Strip Path" primitive, it would correctly output "\\server\dir" for the stripped path and "subdir" for name.

Doing it a second time should return "\\server" for stripped path and "\dir" for name.

Actually I would conquer that this last one is in principle an invalid operation. A path should most probably point to a valid file system location and the server name alone is not such a thing. You can not, even on Windows, take a server name only and use any file IO operations on it. You have for instance to use special network APIs to enumerate the contents of a domain/workgroup or a server. LabVIEW never has so far taken the file IO functions to support directly network resources, most probably since that is quite a flaky thing to do under the various versions of Windows.

I once wrote a "List Network Resources" CIN long ago, that was meant to provide the same functionality for network domains and servers as the native List Directory does for file systems and had all kinds of nasty problems, one of them being that the LabVIEW path type isn't exactly suited to represent such a thing in an easy way.

Of course the Strip Path should definitly not crash on such an operation, but for the rest I would think it operates properly by not returning a valid stripped path for that resource.

[Francois Normandin]

Of course the Strip Path should definitly not crash on such an operation, but for the rest I would think it operates properly by not returning a valid stripped path for that resource.

I see your point.

But I actually thought that it didn't matter if the path was valid or not, i.e. if I put a fake address, it should strip path anyway. I would expect this primitive to be nothing more than a <Search for "\" character and Split accordingly>-type of function. Whether it's "C:\dir" or "\\server\dir" shouldn't make a difference.

If the primitive does something else than what I thought it would be doing, then yes, I'm the one with the problem.

[asbo]

I see your point.

But I actually thought that it didn't matter if the path was valid or not, i.e. if I put a fake address, it should strip path anyway. I would expect this primitive to be nothing more than a <Search for "\" character and Split accordingly>-type of function. Whether it's "C:\dir" or "\\server\dir" shouldn't make a difference.

If the primitive does something else than what I thought it would be doing, then yes, I'm the one with the problem.

I like your logic - I wouldn't -want- it to have more advanced functionality. It's not a Strip and Validate Path, it's just Strip Path. A context-menu setting for validation would be acceptable, but I would contest that getting "\\server" and "dir" should be the proper behavior for a Strip Path node.

[crelf]

It's not a Strip and Validate Path, it's just Strip Path.

I totally disagree - it's strip path, not strip string. What you guys are talking about is manipulating a string, and a path is a different datatype in LabVIEW for a reason. I'm not saying whether the strip path primative works in a way I'd expect - all I'm saying is that paths are not strings, and strings are not paths.

[Francois Normandin]

I totally disagree - it's strip path, not strip string. What you guys are talking about is manipulating a string, and a path is a different datatype in LabVIEW for a reason. I'm not saying whether the strip path primative works in a way I'd expect - all I'm saying is that paths are not strings, and strings are not paths.

What if you want to strip a path that doesn't exist because it's gonna be a directory that will be created later? I think in this scenario, I want the strip path to work as a string parser. Now I understand that different OS have different ways of writing down a filepath and that's what I'd expect the Strip Path primitive to do, while strings are strings on any OS.

[asbo]

I totally disagree - it's strip path, not strip string. What you guys are talking about is manipulating a string, and a path is a different datatype in LabVIEW for a reason. I'm not saying whether the strip path primative works in a way I'd expect - all I'm saying is that paths are not strings, and strings are not paths.

I wouldn't entirely agree - paths are representative of a file system hierarchy and "\\server" is a completely valid node in the UNC hierarchy, regardless of whether standard file system I/O function with that path.

In any event, it seems kind of like LabVIEW is going out-of-scope by deciding that because you can't enumerate that path, you should be given it to work with. It's somewhat similar to LabVIEW deciding to not return "dir" from "c:\dir" when you don't have permissions to "c:\dir". Moreover, LabVIEW will happily crunch out paths on for invalid drive letters all day long.

hooovahh was kind enough to walk by while I was typing this and mention, "Look! Someone on the Internet is wrong!" ...

[smenjoulet]

What if you want to strip a path that doesn't exist because it's gonna be a directory that will be created later? I think in this scenario, I want the strip path to work as a string parser. Now I understand that different OS have different ways of writing down a filepath and that's what I'd expect the Strip Path primitive to do, while strings are strings on any OS.

That's what it does. The path doesn't have to exist for strip path to work. It will give you the stripped path and the stripped name. I haven't had any problems with this.

I think the issue is what it should do with \\server\share UNC name. Rolf explained the technical details. It may not be what you expect, but it is consistent. The nomenclature \\server\share is similar to a drive letter (i.e. X:\). If you try to strip past X:\, you'll get X in the name an empty stripped path, the same as you get for \\server\share.

-Scott

[Marc]

François,

Just reporting a bug I stumbled on recently.

The problem comes when you want to strip a network path that looks like this "\\server\dir\subdir".

When stripping the path with the "Strip Path" primitive, it would correctly output "\\server\dir" for the stripped path and "subdir" for name.

Doing it a second time should return "\\server" for stripped path and "\dir" for name.

Instead, you get an empty stripped path and the input is copied to name output (Incorrect results).

Paths in LabVIEW have always considered \\server\share to be an atomic unit. I rewrote several low-level path functions in LabVIEW and found that strange. Windows is the only platform in LabVIEW that supports this concept (called UNC paths, at least in LabVIEW code).

In 8.0 and 8.2, you'll actually get nothing for "name 2" and <Not a Path> for the stripped path.

Asbo, you're right. I missed that when I rewrote those functions. I'll look into that.

Furthermore, if the stripped path output is wired, it will most likely crash LabVIEW. The current workaround is to assign a drive letter to the network path using "Map Network Drive" in Windows. (Dunno for other OS) It works fine with path that start with "X:\"

I'll look into that. I think if I fix the behavior that Asbo is talking about, the crashes should go away.

Thank you so much for bringing this up.

[crelf]

What if you want to strip a path that doesn't exist because it's gonna be a directory that will be created later? I think in this scenario, I want the strip path to work as a string parser.

Ummmm - it does.

[Francois Normandin]

That's what it does. The path doesn't have to exist for strip path to work. It will give you the stripped path and the stripped name. I haven't had any problems with this.

That's what I meant. We do that all the time.

I think the issue is what it should do with \\server\share UNC name. Rolf explained the technical details. It may not be what you expect, but it is consistent. The nomenclature \\server\share is similar to a drive letter (i.e. X:\). If you try to strip past X:\, you'll get X in the name an empty stripped path, the same as you get for \\server\share.

I think this is right (as Rolf pointed out), and this is exactly what is returned by the function. I would settle for LabVIEW not crashing and a note in the help that would clarify this behavior. It's most probably not unexpected behavior based on what I've read in this thread, but when the help states "returns the last component of a path", for me it means that \\server\dir should be strippable.

François,

Paths in LabVIEW have always considered \\server\share to be an atomic unit. I rewrote several low-level path functions in LabVIEW and found that strange. Windows is the only platform in LabVIEW that supports this concept (called UNC paths, at least in LabVIEW code).

Thank you so much for bringing this up.

Thanks.

[Rolf Kalbermatter]

That's what it does. The path doesn't have to exist for strip path to work. It will give you the stripped path and the stripped name. I haven't had any problems with this.

I think the issue is what it should do with \\server\share UNC name. Rolf explained the technical details. It may not be what you expect, but it is consistent. The nomenclature \\server\share is similar to a drive letter (i.e. X:\). If you try to strip past X:\, you'll get X in the name an empty stripped path, the same as you get for \\server\share.

-Scott

Actually you can verify this further by using the path to string array function. You will see that the first element will be \\server\share as unintuitive that may seem. A quick test in LabVIEW 6 showed that the strip path for such a path retuns Not A Path and an empty name, but doesn't crash. So it seems someone has worked on that functionality to be a bit more consistent but might have messed up something, or used a technique that got troubles with later LabVIEW memory optimizations.