Writing to Program Files -- slow? Lockup?

Z

Z

Hi,

We're using a third party application that keeps its preference files
in "program files\appname" etc.. We are doing some qualifying
testing using Vista running under Virtual Server, in a 1G VM. The
program basically goes to sleep for several minutes when trying to do
this on a "save as", finally reports the file exists (which it
didn't), and if I say "yes" to "replace?" it goes to sleep again for
several minutes and again reports "file exists, replace?" While
we've been working with the vendor for a fix, in the meantime I'm
trying to find us a workaround. A preference file can be created on
an XP box, but even copying it over to the Vista machine I'm running
into issues. If I elevate a cmd.exe to admin, then cd to "program
files\appname", and from there ftp to the XP system to grab the prefs
file, even though the file is only about 5K, the FTP goes off for at
least 5 minutes apparently stalled in the transfer, even though it
should be running with full admin privleges. However, CPU use
according to Virtual Server is high, so it's working on something.

I then tried to FTP to users\admin\documents, which worked fine and
only took a moment. I then used Explorer to copy the file to "program
files\appname." However, then the app seems to stall even reading
the file. However, there are other files in the directory it must
read when it starts up, and they don't seem to take forever, so I
don't know why it should be having trouble with the new one I copied
in. I tried changing the permissions on the entire directory to turn
off read only, in the event the program is trying to write out other
info to its directory in the process, but that didn't help.

I get the general idea of the virtual "program files" directory tree,
and why they wanted to do it, but it appears to me there's a little
more to it than simply Vista creating a virtual tree for each user,
etc.. Something is causing Vista to stall for a REALLY long time
when trying to read or write files to the "program files" tree.

Any idea what's up? Are there some other permissions I need to change
to get this to work? At the moment, I just need a workaround that
will allow me to put a custom file in the application tree under
"program files" and get on with life. But Vista's machinations seem
to be gumming up the works for some reason. Perhaps it's getting hung
up on directory indexing? I haven't turned that off as of yet...
 
S

Stephen

Hi,

We're using a third party application that keeps its preference files
in "program files\appname" etc.. We are doing some qualifying
testing using Vista running under Virtual Server, in a 1G VM. The
program basically goes to sleep for several minutes when trying to do
this on a "save as", finally reports the file exists (which it
didn't), and if I say "yes" to "replace?" it goes to sleep again for
several minutes and again reports "file exists, replace?" While
we've been working with the vendor for a fix, in the meantime I'm
trying to find us a workaround. A preference file can be created on
an XP box, but even copying it over to the Vista machine I'm running
into issues. If I elevate a cmd.exe to admin, then cd to "program
files\appname", and from there ftp to the XP system to grab the prefs
file, even though the file is only about 5K, the FTP goes off for at
least 5 minutes apparently stalled in the transfer, even though it
should be running with full admin privleges. However, CPU use
according to Virtual Server is high, so it's working on something.

I then tried to FTP to users\admin\documents, which worked fine and
only took a moment. I then used Explorer to copy the file to "program
files\appname." However, then the app seems to stall even reading
the file. However, there are other files in the directory it must
read when it starts up, and they don't seem to take forever, so I
don't know why it should be having trouble with the new one I copied
in. I tried changing the permissions on the entire directory to turn
off read only, in the event the program is trying to write out other
info to its directory in the process, but that didn't help.

I get the general idea of the virtual "program files" directory tree,
and why they wanted to do it, but it appears to me there's a little
more to it than simply Vista creating a virtual tree for each user,
etc.. Something is causing Vista to stall for a REALLY long time
when trying to read or write files to the "program files" tree.

Any idea what's up? Are there some other permissions I need to change
to get this to work? At the moment, I just need a workaround that
will allow me to put a custom file in the application tree under
"program files" and get on with life. But Vista's machinations seem
to be gumming up the works for some reason. Perhaps it's getting hung
up on directory indexing? I haven't turned that off as of yet...

Vista now enforces the "don't write to files in the program files
directory" rule.

Set the program to run in XP compatibility mode or have the 3rd party
fix their program.

Stephen
--
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top