The file came back.

[Ray]

Please, let's get some Viserious work done here. Groan.
Now see what you lot have got me doing, and not very good either.

A question, ladies and gentlemen, if you please. I just watched a video by
"Surendra Verma, Development Manager on the Vista Kernel team" about the
Vista transactional file system. I understood very little of what he said,
have to watch it again, and again, however, he said something that made me
wonder if a problem that I've been having is related to this transaction
"snapshot" that Vista seems to use, if I'm understanding that bit correctly.

My problem,
I was running a process (unit) on each core of this computer.
I set it up on the Vista "side".
There is a desktop graphic display that shows me the progress of each unit.
I dual boot with XP where I set the programs up also, so that the registry
would have the correct entries.
I then deleted the XP programs and edited the registry to point the the
drive that Vista is residing on.
Both "sides" are set up to run as a service.

So far so good, it was working well for a couple of weeks, I was able to
boot between OS's and use the same work files. However, a few days ago I
noticed that, in Vista, the one core was not progressing. I opened the log
file and saw that the core had shut down (the work unit, not the actual
core). Task manager showed both cores at 100%, the process was still
running.

In XP it still chugged along, but I noticed that the log was not the same as
Vista's, Huh!
After much poking around I found. . . nothing. The log was not the same as I
was seeing in XP.

Ok, delete the Vista folder that contains the files, go through the registry
and delete any references. Reboot.

Reinstall afresh in Vista, start the services up, verify that two processes
are running, check the log, it should be a brand new one, NOT, it's the same
bloody one from before.
Boot to XP, check all again, a brand new log in the same folder showing all
is well.

I searched in Vista for the log and found about 48 instances of it showing
as a shortcut to the folder, and they seemed to be from different times and
dates. I just deleted them.

I'm wondering if those "shortcuts" could be associated with this snapshot
idea and it kept pulling the same log file up each time. Maybe the process
was working properly, it was just that the log was stuck in a time warp, and
that's where my monitoring program gets its info from, so it didn't update.

Is this a possible scenario? I'm at a loss to explain it any other way.
There's a lot of bright sparks here, any other ideas.

I have it working again, this time I went the other way, installed on XP and
pointed to it from Vista.

Sorry for the long winded ramble.

Ray

 

[Jimmy Brush]

Hello,

This should not be caused by NTFS transactions - that is a feature that an
application has to use explicitly, not something that happens automatically.

This sounds like a problem with "virtualization".

Virtualization is a workaround that Vista uses to allow programs that
misbehave to run in Windows. By misbehave, I mean try to write to files or
registry keys that they don't have access to.

Microsoft has set up special folders that applications are allowed to write
to, and everywhere else is hands-off. This has been the way things have been
done for years now, but many programs don't follow these rules because until
now these rules have not been enforced by default.

Here's how Virtualization works:

- Program, we'll call it badapp, opens its data file in c:\program
files\badapp\data.dat
- Program does stuff
- Program attempts to save file

At this point, the program doesn't have permission to write the file
(program files is read-only!). So, Windows decides to be sneaky, and here's
what it does:

- Windows saves a copy of the file to
c:\users\joebob\appdata\local\virtualstore\programdata\badapp\program
files\badapp\data.dat, or something like that, and DOES NOT change the
original file.
- Windows tells badapp that everything worked fine - no problems.
- Windows remembers that it has saved a copy of that file to the new
location for badapp
- From now on, whenever badapp OPENS c:\program files\badapp\data.dat,
Windows will instead load the COPY of the file, and work with only the copy.

So, it sounds like this is what is happening with you. When your program is
saving the data file, the data file is located in a folder that the program
does not have access to - so Windows sneakily redirects a copy of the data
file to a different place.

After Windows has redirected a file, your program no longer sees the
ORIGINAL file. So, Windows Vista won't pick up changes to the file that
Windows XP made, and vice versa, because XP is working on the ORIGINAL file,
and Vista is working on its COPY of the file.

So ... what's the solution? Well, the easiest solution is to change
permissions on the folder that your program writes stuff to.

1) Open an "administrator/root" explorer
- Click start
- Type explorer
- right-click windows explorer
- click run-as administrator

2) From the admin explorer, allow access from Vista
- Browse to the folder you need access to
- Right-click it
- Click Properties
- Click security tab
- Click Edit
- Click Add
* If only your account needs acces, type your username
* If every account on vista needs access, type: Users
- Press enter
- Click the checkbox under Allow next to Full control
- Click OK
- Click OK

OK ... now we need to tell windows not to use virtualization for your
program.

- Start up your program
- Open Task Manager
- Click Processes tab
- Find your program
- Right-click it
- If there is a checkmark next to "Virtualization", click it to uncheck it

You may need to reload your data file at this point.

- JB

Vista Support FAQ
http://www.jimmah.com/vista/

 

[Ray]

Thanks Jimmy, yes that does sound like the problem. Thank goodness for
people like you around, you are very Vistaluable to us mere mortals.
Everything is working good right now, but then I haven't switched over to XP
yet, I'll report back after I do.

Ray

 

[A1ex P1antema]

In schreef Jimmy Brush:

This sounds like a problem with "virtualization". ....
Here's how Virtualization works:

- Program, we'll call it badapp, opens its data file in c:\program
files\badapp\data.dat
- Program does stuff
- Program attempts to save file

At this point, the program doesn't have permission to write the file
(program files is read-only!). So, Windows decides to be sneaky, and
here's what it does:

- Windows saves a copy of the file to
c:\users\joebob\appdata\local\virtualstore\programdata\badapp\program
files\badapp\data.dat, or something like that, and DOES NOT change the
original file.
- Windows tells badapp that everything worked fine - no problems.
- Windows remembers that it has saved a copy of that file to the new
location for badapp
- From now on, whenever badapp OPENS c:\program files\badapp\data.dat,
Windows will instead load the COPY of the file, and work with only
the copy.

I've been struggling with this phenomenon as well. I edited a text file in a subdirectory of Program Files, just to test file protection. After saving the file, I found the date and time didn't change, and Notepad showed the original contents. It makes you wonder which version is the "real" one, and it makes other text editors seem unreliable. Previous versions of Windows wouldn't allow me to save the file, and I would have chosen another location. No problem.

This kind of behaviour doesn't make using computers easier. Instead it makes it harder to understand, and might turn people away from them.

It is a severe security breach as well. Suppose I would want to remove some sensible information from a file before publishing it, then I could easily publish the wrong version! An operating system shouldn't try to fool its users and hide its true behaviour. The people who invented this "feature" should hang from the highest tree.

 

[A1ex P1antema]

In schreef A1ex P1antema:

Suppose I would want to remove some sensible information from a file

sensitive is what I meant.