Jump to content

Seem to have install folder left on drive


oioldman
 Share

Recommended Posts

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!!

Link to comment
Share on other sites


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

Link to comment
Share on other sites

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 :blushing:

Edited by Fencer128
Link to comment
Share on other sites

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.sifpost-17928-1142364386_thumb.jpg

Link to comment
Share on other sites

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 by Fencer128
Link to comment
Share on other sites

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 by oioldman
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by myno
Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

@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.

Link to comment
Share on other sites

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 by myno
Link to comment
Share on other sites

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

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

  • Recently Browsing   0 members

    • No registered users viewing this page.


×
×
  • Create New...