nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

iwgetmount.exe takes up to 40 seconds to return anything

System

TS 6.5SP2, Win2003

I have a script from which I'm calling TeamSite::Config::iwgetmount(). The script is otherwise optimized, etc. so when I found that it took almost a minute to run, I started isolating the problem to which line was causing the issue.

It seems that iwgetmount() was doing it. Within the Config module, I've isolated the problematic line to where it runs a system call to iwgetmount.exe. Sure enough, when I run this on the command line, it takes anywhere from 18 to 40 seconds for this command to return anything.

Why?!

Is there something internal to this command that looks for something that my implementation does not have set up properly, perhaps? Why would this command take so long to run? I noticed this weeks ago, when I started working with this script, and now that I'm finishing it, I'm trying to clean up any spots.

Dave

Find more posts tagged with

Comments

Valentine

If you take a look at the TeamSite/Config.pm, iwgetmount uses a CLI application to get the variable.

$iw_home/bin/iwgetmount

Try running it from the command line.

How is the backing store? Is it available at all times?

Migrateduser

Okay, I don't think you read my entire message. I tried it from the command line, which is as granular as a non-Interwoven engineer can get it.

Yes, the backing store is available.

nipper

Strange, I run it on both of my 6.7.1 systems and it returns immediately. Try iwgetstore or iwversion, & iwgetlocation -l iwmount

Any issues with them ?

Migrateduser

All 3 of the commands you suggested are just fine ("iwgetlocation -l iwmount" returns a syntax error in 6.5 but "iwgetlocation -c iwmount" works well).

I'm puzzled.

nipper

That is strange, so it is only 1 CLT ?

I wonder if it is trying to do an RPC call, then timing out and getting the information.

Is localhost set & pingable ?

You can change teamsite::config to use iwlocation rather than iwgetmount

Or you can pull a smitty and just keep whining about it. :cool:

Migrateduser

Yes, it's pingable -- I have no idea how the binary is getting the mount point but I don't imagine it's much different from iwgetlocation. So, for now I'll change Config.pm to use iwgetlocation and I guess when my customer upgrades, I figure that the command will self-correct (?!)

I'm wondering if someone from engineering could reply to this.

Dave

ccprofessional

TS 6.5SP2, Win2003

I have a script from which I'm calling TeamSite::Config::iwgetmount(). The script is otherwise optimized, etc. so when I found that it took almost a minute to run, I started isolating the problem to which line was causing the issue.

It seems that iwgetmount() was doing it. Within the Config module, I've isolated the problematic line to where it runs a system call to iwgetmount.exe. Sure enough, when I run this on the command line, it takes anywhere from 18 to 40 seconds for this command to return anything.

Why?!

Is there something internal to this command that looks for something that my implementation does not have set up properly, perhaps? Why would this command take so long to run? I noticed this weeks ago, when I started working with this script, and now that I'm finishing it, I'm trying to clean up any spots.

Dave

Looks like a windows issue.
If you have network mappings windows takes a lot of time (especially if they dont resolve right away) to map all the drives.

ccprofessional

As a test, I would disconnect all printers and network drives to the TS host and try the same again.

Migrateduser

Interesting -- this machine doesn't have any printers attached to it but it does have just about every letter reserved for network drives. Might that be it?? I'd really rather not disconnect them because, unless there's a shortcut or technique that I'm not aware of, I'd have to remap those things one by one.

ccprofessional

You should be able to reach Bill G 9am - 5pm pacific.
Here's his # http://www.lockergnome.com/nexus/news/2005/09/28/whoops-palm-ceo-shows-live-audience-bill-gates-cell-phone-number/

I heard he's a slacker ;-)

How's windows explorer doing?

Migrateduser

Yeah, the best part of that is some poor SOB who posted a comment at the bottom of that article:

i would like to have Bill Gate cell phone no. thank you

ISCBorisB

Interesting -- this machine doesn't have any printers attached to it but it does have just about every letter reserved for network drives. Might that be it?? I'd really rather not disconnect them because, unless there's a shortcut or technique that I'm not aware of, I'd have to remap those things one by one.

Create and test upfront a batch (cmd) file using NET USE commands to map all resources. See here
If you have time, you may parse a result of "net use" to generate "net use <letter> UNCPath" to re-apply later

ccprofessional

Create and test upfront a batch (cmd) file using NET USE commands to map all resources. See here

There's always a long way to do the same thing ;-)

When you use Windows Explorer and try to, say, create a new file, it builds the directory structure for you - probably using the same underlying windows api. If it's a network mapping issue, you will see that it takes forever to show you the tree.

Migrateduser

Brilliant! That was it! So, iwgetmount, perhaps among other things, polls the network drives in order to get the VFS mount location? How inefficient! That can only be as good as the operating system / network environment and knowing how my customer's environment is (unfortunately) Microsoft-based, you can imagine what a great performer it is.

So, I guess I can kiss the iwgetmount command goodbye?

Still, this seems short-sighted of IW to have the command examine the network mounts.

ISCBorisB

There's always a long way to do the same thing ;-)

You've missed the point. That was a reply to Dave's remark "unless there's a shortcut or technique that I'm not aware of, I'd have to remap those things one by one"

ccprofessional

You've missed the point. That was a reply to Dave's remark "unless there's a shortcut or technique that I'm not aware of, I'd have to remap those things one by one"

define "shortcut"

ccprofessional

Brilliant! That was it! So, iwgetmount, perhaps among other things, polls the network drives in order to get the VFS mount location? How inefficient! That can only be as good as the operating system / network environment and knowing how my customer's environment is (unfortunately) Microsoft-based, you can imagine what a great performer it is.

So, I guess I can kiss the iwgetmount command goodbye?

Still, this seems short-sighted of IW to have the command examine the network mounts.

It's Microsoft Windows, silly!

TS talks to OS, OS finds *yawn* network drives at its own pace and returns list to TS. your script is waiting for this MS brain f6rt to complete

nipper

And the CLT man page is of no help, for 6.7.0 the Windows CLT manual says it reads /etc/defaultiwmount

If you have the 6.5 CLT manual, what does it say ?

Also, for 6.5 how big is the binary ? In 6.7 it is 532 KB about the size of iwgetlocation. I was just wondering if in 6.7 they changed the way it behaves.

Andy

Migrateduser

your script is waiting for this MS brain f6rt to complete

I understand that, Windows being a Microsoft product, my expectations should be substantially lower than they are -- and just when I think they've gotten as low as they could get... but first of all, I wouldn't call it a MS brain fart as much as I'd call it a Bill Gates ClusterF#&k (note the tech-friendly CamelCase in the censored word, by the way).

So, if iwgetmount works so poorly (at least, in my instance), why would iwgetlocation work so well in comparison? The two commands are getting their information differently so, not knowing intimately how iwgetlocation works, why wouldn't iwgetmount work the same way?

ISCBorisB

define "shortcut"

If you insist...

1. run "net use > reconnect.cmd"
2. Modify reconnect.cmd manually, it already has all you need. Basically, you have to modify left hand status (Unavailable, Disconnected, etc) to 'net use'
3. Run reconnect.cmd later when you want to restore (disconnected) assets

Union_report.rptdesign

nipper

So, if iwgetmount works so poorly (at least, in my instance), why would iwgetlocation work so well in comparison? The two commands are getting their information differently so, not knowing intimately how iwgetlocation works, why wouldn't iwgetmount work the same way?

iwgetlocation just reads the iw.cfg and returns the specified variable.

Migrateduser

Andy,

In the 6.5 Windows documentation, it reads that the CLT displays the contents of /etc/defaultiwmount . Gotta love that, huh? Why does Interwoven even bother to appear as though they're putting out different documentation for Windows versus Unix?! I'd love to be on the Documentation QA team. It must be nice to be paid for (apparently) doing nothing.

The two commands iwgetmount and iwgetlocation are exactly the same size in bytes in 6.5: 540,672. Still, iwgetlocation works immediately and doesn't appear to scan the network drives.

Dave

nipper

so then in 6.7 it is a good bet that iwgetmount behaves the same in 6.7 as it does in 6.5

Change TeamSite::Config.pm seems to be the best option.

Then file a bug/enhancement req

Migrateduser

Yes, I actually changed Config.pm two pages ago. But is this really a bug? It may appear to be a bug or at least bad design but maybe there's a reason that it hangs when perhaps trying to read network drives. I tend to think that as the reply count to this thread gets higher, someone from Interwoven might respond.