Seem to have install folder left on drive

[oioldman]

Hi,

I've suddenly noticed that a folder named $winnt.~ls$ is on the c: after completing a RIS install inc apps.

I'm not sure what i may have done to make this happen, as not changed way i do a RIS build.

It doesn't have any attributes applied to the folder, and can be deleted manually with no issues, not able to delete via cleanup.cmd or runonceex.cmd.

Any body know what and where this folder comes from?

oioldman

P.S - A search of $winnt.~ls$ on google produces results without that phrase in the sites!!

[Fencer128]

Hi,

Can you just confirm - are you using RIPREP or RISETUP images?

Thanks,

Andy

[oioldman]

Hi Fencer128,

I used risetup to create the original folder structure then added the $oem$ structure and modified the .sif as required.

It worked with no issues and i'm not aware of having done anythng to cause this sudden change.

RIPREP - never used - not keen on it.

oioldman

[Fencer128]

Hi,

Given that you're using RISETUP, I really don't know why you're seeing that file - I certainly don't.

Could you post a brief synopsis of the contents and paths in $OEM$, as well as any post install scripts that you run. Posting your SIF file could be useful too - so long as you remember to blank your password and product keys.

Cheers,

Andy

EDIT: Changed RIPREP to RISETUP above. I meant it - but rushed my typing

Edited March 14, 2006 by Fencer128

[oioldman]

OK,

Hopefully i've managed to attach a .jpg of the folder structure and a copy of .sif with details removed where necessary.

Knowing my luck, the answer is obvious, but i can't see and thanks for helping.

NOT using riprep either, if i didn't make clear before.

Snow over last few days must have been fun....

OiOld

apps.sif

[Fencer128]

Hi,

You're right - the snow WAS fun (drove from Cumbernauld to Dundee on Sunday evening).

I had a look at your folder structure, and there are a couple of things that you do - that I don't. Since I do not have the problem you do, we can assume that the problem could lie with the extra processes associated with these folders.

They are:

$$
|
|--oemdir
|
|--Resources
|
|--System32
	   |
	   |--dllcache

$1
|
|--Install
	   |
	   |--Apps
			|
			|--dotNet
			|
			|--Firefox

I will assume that simple file placements should be fine - which leaves the .NET and Firefox installs. I suspect that one or other of these is not terminating or completing correctly and is leaving temp/working files.

Could you try building without these to see if you can isolate the problem? If the problem disappears then try with each in turn to see which is causing the issue. If removing them does not fix the problem then we should look at the contents of your .CMD files next.

Good luck,

Andy

Edited March 17, 2006 by Fencer128

[oioldman]

Andy,

Thanks for the assistance.

Did try with out those being installed and still had same issue.

Then remembered that ZoneAlarm doesn't always reliably install ocross lan, so rem'd those lines from runonceex.cmd and no issues.

Am doing again to confirm, but thought i'd provide a progress update.

cheers,

neilw

Edited March 20, 2006 by oioldman

[oioldman]

it still had folder after rem'ing out ZoneAlarm, so did it live and no issues at all - must be a vmware thing, but no idea why as not seen before.

if I notice a particular cause & resolution will reply.

[myno]

atm i have the same wiered problem as oioldman.

- win2k3 risserver deploying w2k wxp w2k3 images

it happens on every deploy, no matter if plain or full of apps&patches

it's been awhile since i recognized the problem but now i have the time to analyze it more seriously.

i hope u'r also still on the ride oioldman B)

Edited March 29, 2006 by myno

[Fencer128]

atm i have the same wiered problem as oioldman.

- win2k3 risserver deploying w2k wxp w2k3 images

it happens on every deploy, no matter if plain or full of apps&patches

it's been awhile since i recognized the problem but now i have the time to analyze it more seriously.

i hope u'r also still on the ride oioldman B)

Hi,

Do you use RISETUP or RIPREP?

Cheers,

Andy

[myno]

Do you use RISETUP or RIPREP?

my setup and most of the folders are equal with the steps oioldman did.

"I used risetup to create the original folder structure then added the $oem$ structure and modified the .sif as required."

i don't have this issue since the begining of my ris, it happend around half a year later while my rissystem grows and got more complex.

[oioldman]

@myno,

do you get this when testing in vmware or on 'real' pc's? as i noticed that it does happen more frequently in vmware and that an app can potentially cause if installed from the $oem$\$1\install folder, as fencer128 pointed out if an app doesn't install correctly, in my case ZoneAlarm.

Doing an MS or google search shows nothing, but ~bs is used for teh temp boot area when building.

[myno]

I have the problem on every single pc and vmware machine.

after a lot of testing since yesterday, i found out that the problem depends on my .sif

i'll now go for an "cut'n'rip'" trip to see which line could cause such a problem.

as i noticed that it does happen more frequently in vmware and that an app can potentially cause if installed from the $oem$\$1\install folder, as fencer128 pointed out if an app doesn't install correctly, in my case ZoneAlarm.

i dont believe that this can happen through such an app, because $winnt.~ls$ is the folder from where the data gets pushed to $1/foldername. For your case it would mean that zonealarm gets installed from C:\install\apps\zonealarm\setup.exe not from c:\$winnt.~ls$\$1\apps\zonealarm\setup.exe. If the ZA setup would get stuck, your problem would be the copyed install folder itself not the $winnt.~ls$ which should be already gone at this phase.

Edited March 30, 2006 by myno

[oioldman]

ah, but if you open the $winnt.~ls$ folder it also contans the $OEM$\S1 structure so anything installed via that could otentially be an issue.

At least you've found the problem, enjoy tryig to fix