Re: Application caching
I completely understand what you are saying but you are not understanding
that this is normal Windows behaviour. You've argued the point and made my
point to your repeated references to how a single user Windows system works.
You are not used to working with Windows when dealing with multiple users on
the same system. To conserve memory, windows shares a readonly file in
memory. That is why you are seeing this. This is NOT caching. Windows
doesn't cache applications.
This is obviously not getting anywhere. What you are seeing is normal based
on Windows OS. I would highly suggest calling Microsoft as the forum is not
giving you the answer you want. Calling htem directly and talking with them
and ask them to change the OS behaviour will at least let them know what you
want from the OS.
Let me ask you this. On Windows XP or whatever client OS you are using, if
you start the app, replace the file, then try to start it again while the
app is running, what happens? does it start the new version?
Jeff Pitsch
Microsoft MVP - Terminal Services
"Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message
news:LC_ek.5530$5A2.4792@newsfe29.ams2...
>I guess you aren't understanding the situation, so I'll make it clear
>again:
>
> - User1 to User8 are logged in in TS and all have app.exe (v1) running.
> - app.exe (v1) is changed on the NAS to a new version (v2).
> - User1 closes app.exe (v1) and opens app.exe (v2) from the NAS, but sees
> app.exe (v1) appearing on his screen.
> - User1 logs out from TS, logs in again and tries to open app.exe (v2)
> from
> the NAS. Again, he sees app.exe (v1) appearing.
> - User1 to User8 all close app.exe (v1).
> - User1 tries to open app.exe (v2) from the NAS, but still gets app.exe
> (v2).
> - User1 logs out again from TS, logs in again to TS and tries to open
> app.exe (v2) from the NAS. Again, he sees app.exe (v1) appearing.
> - Bored like hell, we ask User1 to User8 to log out from TS.
> - User1 logs in again to TS and tries to open app.exe (v2) from the NAS.
> Finally he sees app.exe (v2).
> - User2 to User8 log back in into TS, open app.exe (v2) from the NAS and
> can
> work again with app.exe (v2).
>
> Don't tell me that is 'standard OS behavior'.
>
> The NAS is not caching anything, as app.exe (v2) appears on the desktop
> workstations after a close of app.exe (v1) and opening app.exe (v2) from
> the NAS.
>
> PS: I'm used to multi-user environments. In LTSP for example, I haven't
> seen
> any behavior like this before.
>
> Regards,
> Toni
>
> Jeff Pitsch wrote:
>
>> I would highly recommend getting to know TS first before saying anything
>> about it's security. It is very secure and it's your unfamiliarity with
>> how
>> windows uses memory that is causing the issue here. This has nothing to
>> do
>> with TS but with Windows in general and almost all OS's. They all work
>> the
>> same. You are simply used to working in a singloe user environment which
>> is why it's difficult to understand why this is happening.
>>
>> Again, this is not a bug but the way windows works. Your even confirming
>> by saying that users log out and log back in to get the new exe to load
>> into
>> memory. Why would TS function any differently? Your app isn't
>> dynamically loaded when it changes, again, why would you expect TS to
>> function any differently.
>>
>> I will say this again, this is not TS but the way windows works and your
>> unfamiliarity with terminal services and muti-user. If security was an
>> issue like you seem to think it is, well, I know I personally wouldn't
>> have been able to load/configure/architect solutions in some highly
>> secure
>> areas where something like this wouldn't be tolerated.
>>
>> Jeff Pitsch
>> Microsoft MVP - Terminal Services
>>
>>
>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message
>> news:KNFek.151686$Kb.28741@newsfe29.ams2...
>>> 1) Changing software during daily work is common here (multiple reasons
>>> for
>>> that).
>>>
>>> 2) Workstation users have no problems closing the app and starting it
>>> again
>>> to use the new version.
>>>
>>> 3) Still, using shared memory from other user sessions is ... very
>>> secure.
>>>
>>> 4) I didn't mention Office as software , I did mention an application we
>>> develop ourselves. And this application has descent library usage. The
>>> only
>>> thing a user need to reload, is the main exe, which should be possible
>>> with
>>> a single close->reopen.
>>>
>>> 5) If the exe is still in memory, it should read it from disk again if
>>> it
>>> has changed on disk! What would be the point of the modification date
>>> then?
>>>
>>> I have my serious doubts about TS, security wise and multi-user wise.
>>>
>>> Anyway, seems we have to live with this bug.
>>>
>>> Regards,
>>> Toni
>>>
>>>
>>> Jeff Pitsch wrote:
>>>
>>>> No this is standard and if you really think of the consequences of
>>>> changing an executable while being used you'll realize this is for the
>>>> better. Remember, just because something is in memory doesn't mean it's
>>>> not be ing
>>>> used off the disk or locked. You also have to realize that making
>>>> changes
>>>> to a program in the middle of the day is NOT normal by any stretch.
>>>> You
>>>> always make changes on a scheduled basis. Also due to shared memory of
>>>> windows, just because an executable has changed doesn't mean it gets
>>>> reloaded. The exeuctable is already in memory, why should it reload
>>>> the
>>>> entire thing again?
>>>>
>>>> Can you imagine upgrading Office while users are using the software?
>>>> What
>>>> a disaster that would be.
>>>>
>>>> Jeff Pitsch
>>>> Microsoft MVP - Terminal Services
>>>>
>>>>
>>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in message
>>>> news:ghKdk.157661$8H5.84843@newsfe10.ams2...
>>>>>I would expect such a behavior for every user session, but not for all
>>>>>users
>>>>> logged in at the same time.
>>>>>
>>>>> In correct multi-user environments, every user has it's copy of the
>>>>> program
>>>>> cached in memory, but it is unlikely that when the user closes the
>>>>> application and start it again, that the OS wouldn't read it again
>>>>> from
>>>>> disk (specially when it has changed).
>>>>>
>>>>> So now we are stuck for program updates. Terminal Server users have to
>>>>> collectively log out of their sessions before they can use the new
>>>>> software
>>>>> version.
>>>>>
>>>>> I don't think that is 'standard OS behavior'. That is a serious bug.
>>>>>
>>>>> --
>>>>> Regards,
>>>>> Toni Van Remortel
>>>>>
>>>>>
>>>>> Jeff Pitsch wrote:
>>>>>
>>>>>> This is standard OS behaviour. I'm not sure what your expecting.
>>>>>> Windows
>>>>>> has to make sure that the application is "locked" in case it needs to
>>>>>> read
>>>>>> from it again. If the application is changed in the middle of user
>>>>>> using it the implications include crashing the user's application and
>>>>>> potentially session and potentially worse.
>>>>>>
>>>>>> Jeff Pitsch
>>>>>> Microsoft MVP - Terminal Services
>>>>>>
>>>>>>
>>>>>> "Toni Van Remortel" <toni.van.remortel@p-NOSPAMops.be> wrote in
>>>>>> message news:RGGdk.121644$jB5.81602@newsfe05.ams2...
>>>>>>> Hi all,
>>>>>>>
>>>>>>> We have set up Server 2008 with Terminal Server for about 10 users.
>>>>>>> All those users use the same application (a single exe from a
>>>>>>> network
>>>>>>> share).
>>>>>>>
>>>>>>> The drawback is that when we update the application (in-house
>>>>>>> development),
>>>>>>> we need to ask all TS users to log out before they can use the new
>>>>>>> version.
>>>>>>> Somehow, the exe is cached by the TS server as long as someone has
>>>>>>> it
>>>>>>> open,
>>>>>>> and TS does not check if the exe on the network share is updated.
>>>>>>>
>>>>>>> Is there a way to disable this behavior? When we update the
>>>>>>> application, a simple close and reopen should open the new version,
>>>>>>> not
>>>>>>> the old cached
>>>>>>> version.
>>>>>>>
>>>>>>> Thanks a lot.
>>>>>>> --
>>>>>>> Regards,
>>>>>>> Toni Van Remortel
>>>
>>> --
>>> Regards,
>>> Toni Van Remortel
>
> --
> Regards,
> Toni Van Remortel