tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From André Warnier>
Subject Re: runtime.exec "cmd.exe /C net use"
Date Tue, 26 Mar 2013 20:07:34 GMT
Patrick Flaherty wrote:
> On Mar 25, 2013, at 1:15 PM, Howard W. Smith, Jr. wrote:
>> On Mon, Mar 25, 2013 at 11:14 AM, Patrick Flaherty
>> <>wrote:
>>> Update: If I'm login interactively (meaning machine boots and I login 
>>> and
>>> get my desktop) and that interactive account matches the service login
>>> account
>>> then "net use" from within the service does return all mapped drives.
>> I expected as much. It seems as though you cannot get away from the
>> requirement of having to login 'first' get everything working as
>> designed/expected in your app.
>> Excuse me, if I missed the business requirement specification (earlier in
>> this conversation), but is the requirement only to get a list of mapped
>> drives for 'your' user login or any enduser that logs into the production
>> server/client/PC/machine?
>> can you add the list of network drives to a database table, and maintain
>> the database table and retrieve the list from that database table via the
>> tomcat-app-running-as-service?
>> if you only need a list of mapped network drives for your user login, can
>> you just maintain a 'file' that has this list on the target/production
>> server, and whenever it changes, can you update the file, and make the
>> topcat-app-running-as-service to always read the file instead of 
>> having to
>> call 'net use'?
>> IMHO and FWIW, i would never go with the approach of relying on a windows
>> 'command line' to do this/that for me. yes, in my app, i allow 
>> endusers to
>> update files/documents, and the app saves the files/documents to a 
>> certain
>> folder on the server, and my app will list those files on a web page, and
>> they can view/download those files from/via the web app... all that is 
>> done
>> via java instead of doing a 'cmd.exe dir'. i'm new to java, always wanted
>> to be java developer, and loving what i can do with java. i'm almost
>> getting to the point, where my days of a 'windows user' are done... one
>> day, i hope to migrate to linux for target server instead of windows
>> server. :)
> This is what I see. If my service logs in as "service-user" and I login 
> normally to my desktop as "dt-user".
> I call "net use" from my service and get an empty list. Now I logout as 
> "dt-user"and login as "service-user" and I mapped
> 4 drives and only 2 of the drives are mapped persisted (i.e. reconnect 
> at logon). I logout as "service-user" and
> now I have my app call "net use" programatically and it returns the 2 
> drives that were mapped with persistence.
> Conclusion: Whatever drives are mapped persisted when logged in as the 
> user the service logs in as, then your
> app can call "net use" and get those drives returned from "net use" even 
> if your logged in as "dt-user" OR nobody
> is logged in at all !!!!
> Maybe someone can confirm my finding, but this is what I see.

Hi Patrick.
Basically, what Jeffrey and I are trying to tell you :
- we are not saying that your observations above are incorrect, in the context in which 
you are making them
- but it seems to us that the way you are going about this, is not the right way to make 
your application portable to other systems or Windows versions, because it seems to rely 
on things that may be particular to one or the other Windows version or circumstance.
In other words, it makes your application "fragile".

The point is : when you login interactively to a Windows computer as "user-1", or when you

run a Service which logs-in to that computer as the same "user-1", the environment in each

case is *different* in many ways.  It may be that under one or more particular versions of

Windows, when comparing certain particular aspects (like prior drive mappings), you cannot

see a difference.  But differences there are, and they may show up on another version of 
Windows that you have not tried yet, or maybe with the same version somewhere else which 
has other "network policies" or "security policies" than the ones you are testing under 
right now.

If you totally control your environment, notice that something is working and are happy 
with that because you are never going to use this anywhere else, then that's fine, keep 
doing it and don't spend more time figuring out what may be or not portable somewhere else.

But if you want to make something portable, then you have to take into account that, for 
example, the host on which your app may be running one day, will not allow you to login 
interactively ahead of time to make drive mappings for the service's user-id.
For example, because the sysadmins have decided that anything that runs as a service needs

a special "service account" (which, contrarily to all the others has a password that never

runs out e.g.); but on the other hand, according to their organisation's rules, a service

account can *not* be used to login interactively anywhere. And since this rule already 
applies to the 10,000 workstations and servers of that organisation, they are not going to

change it just for you.

And I believe that now, we are really far from any topic that relates to the 
Tomcat-specific help that is the point of this mailing list.

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message