phryder

Member
  • Content count

    6
  • Joined

  • Last visited

Community Reputation

0 Neutral

About phryder

  • Birthday 02/29/1948

Contact Methods

  • Website URL
    http://

Profile Information

  • OS
    XP Pro x86
  1. Problem Solved Thanks to -X- Well, the security tab did not exist in the file/folder properties window. Didn't take me too long to figure out (with a little Google help) that I needed to uncheck Use simple file sharing (Recommended) on the View tab in the folder options window of the Tools menu, Folder Options... of Windows Explorer. Gee, I have never used this feature before. Anyhow, after getting the Security tab to make an appearance I checked the Deny box for the Write function in the Permissions for Administrator window and, for good measure, did the same for all the other listed Group or user names. Learning the nuances of all this security stuff is a whole new ball game for me. Now, when I open nLite on a Windows installation folder that I have "write deny" enabled on nLite pops up a Warning! "Select where to save the CD installation files for modification. Choose or create an empty folder." In other words nLite will not write back to my source which, in effect, saves me from myself in the event that I inadvertently opened a project that I did not want to modify. Am I the only fool working on the computer in the wee hours of the morning with my favorite beverage nearby? johnhc... You are correct about the 'read only' coming back. If one clears the read only attribute on a Windows installation file it will be set again the next time you look at it. Strange. Makes one wonder who is in control of the computer. Obviously it's not the Administrator. Likewise, I can confirm mara's observation that nLite clears the read only attribute on all files. I also believe that my experiment proves that nLite writes over a read only file. Pretty easy to do if you clear read only attribute first. I really don't know what a read only file is anymore. Thanks again to -X-
  2. Experiment: Create directy on hard drive, let's call it xpgold. Insert original xpgold cd into the cd drive. Copy the cd to xpgold folder. Open Windows explorer and observe that... 1. xpgold folder and all sub directories are read only. 2. randomly check a few files, observe that read only attribute is not set. Navigate to the xpgold folder... right click Properties clear the read only attribute click Apply, in the popup select "Apply changes to this folder, subfolders and files." Click OK. Windows does it thing, took my pc about 15 seconds, then brings you back to the Properties screen. Now set the read only attribute, click Apply, and in similar fashion select "Apply changes to this folder, subfolers and files." Click OK twice and close explorer. Open explorer again, check as many files as you want and observe that the read only attribute is set. Let's especially look at txtsetup.sif in the i386 directory. I notice that mine says, Modified: Thursday August 23rd 2001 7:00:00 AM and that the read only attribute is set. At this point I am satisfied that everything is read only. Now let's go to nLite (I am using 1.4.9.1) and load xpgold from the hard drive, select unattended, and do something like enter a product key, build it, and exit. Now open Windows Explorer, navigate to txtsetup.sif and... the read only attribute is cleared and the date modified is, well, today. I observe that the read only attribute is cleared on all the files. Hmmm. So...what I am trying to figure out is how to make one of my creations really "read only" so that I do not inadvertently modify it. Any ideas? Did I do something wrong? Mara... Just read your post. I wonder if there is something in gpedit that will get me where i want to go.
  3. Say, for instance I create a project with nLite or another program, such as slipstreaming sp3 with XPgold source. Let's call it XPsp3source. Well, that is a logical starting point for many future projects that I would typically start by copying XPsp3source, renaming it to whatever, then going at it. XPsp3source is. in my mind, a reference point that I never want to change. Nlite and other programs apparently have no problem modifying files and folders that have the read only attribute set. What I want to know is if it is possible to do something to a folder so that it and it's contents cannot be changed by programs such as nLite.
  4. I have noticed that nLite modifies the source even if the folder's read only attribute is set. Well, every now and then by mistake I load something into nLite that I really did not want to modify. So, my quetion is, is there a way to harden a folder (and its contents) so that programs like nLite cannot modify it?
  5. I have managed, thanks to all the contributors of MSFN, to put together a slipstreamed, nLite, RyanVM, Bashrat CD. It takes somewhat less than an hour to load, fully unattended. I have a scratch server in the shop running Windows 2000 Server that I can do whatever I want to with. I was wondering how much time could be saved, if any, using RIS over a CD install.
  6. I have never used RIS and am wondering if I am missing the boat. Does an RIS install have a speed advantage over a CD install? Thank you in advance for your comments.