I run a dual-boot (a microsoft freebie when I installed Win7 on top of
XP) and like it very much. I spend most of my time in XP, mostly
because all my software works here. More about that later. I have long
used a .bat file that runs on XP shutdown. Can't even remember how I
did that but it works. It uses
xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* etc
to copy all of Eudoras email mailboxes to a locaton on another
physical drive. If I have a catastrophe and have do a Macrium Image
Restore (from a week or so back) on my XP system, when it's done I use
another .bat file to copy the latest emails from that latest shutdown
back into my image-restored Eudora. It's always worked swell for me.

Yes, Eudora email client is W-A-A-A-Y out of date but it is the best
email I've ever been able to find to fit my needs. A lot of people
still hang onto it, but the eudora newsgroup is not as savvy about all
computer stuff as this one.

As time goes on I HAVE to spend more time in Win7 cause websites are
refusing to respond to my XP's Firefox. Or refuse to work right, like
when I enter my credit card and they go into la-la land. And other
nasty stuff.

When I do visit my Win7 installation I don't care to have its Eudora
download all the email that IT hasn't seen yet and I have to then sort
it all out. It occured to me I might run another .bat file from XP
into Win7's Eudora. When I'm in XP the Win7 install shows as D: in
Windows Explorer. So:
xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* D:\"Program
Files (x86)"\Qualcomm\Eudora\mydata1\*.*

After running this .bat I see the In.mbx of Win7's Eudora change to
match the size (bytes)of the XP's Eudora, so the bat works.

However, when I boot into Win7 and activate Eudora over there I don't
see the same In.mbx that I copied over from XP. This Eudora chooses to
only display the emails that it has downloaded off the server for
itself.

Xxcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* D:\"Program
Files (x86)"\Qualcomm\Eudora\mydata1\*.*

XP is 32 bit and Win7 is 64, but Eudora runs in Program Files (x86) so
that shouldn't matter.

Does anyone have a guess why Win7's Eudora is acting like this?

John B. Smith wrote:
> I run a dual-boot (a microsoft freebie when I installed Win7 on top of
> XP) and like it very much. I spend most of my time in XP, mostly
> because all my software works here. More about that later. I have long
> used a .bat file that runs on XP shutdown. Can't even remember how I
> did that but it works. It uses
> xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* etc
> to copy all of Eudoras email mailboxes to a locaton on another
> physical drive. If I have a catastrophe and have do a Macrium Image
> Restore (from a week or so back) on my XP system, when it's done I use
> another .bat file to copy the latest emails from that latest shutdown
> back into my image-restored Eudora. It's always worked swell for me.
>
> Yes, Eudora email client is W-A-A-A-Y out of date but it is the best
> email I've ever been able to find to fit my needs. A lot of people
> still hang onto it, but the eudora newsgroup is not as savvy about all
> computer stuff as this one.
>
> As time goes on I HAVE to spend more time in Win7 cause websites are
> refusing to respond to my XP's Firefox. Or refuse to work right, like
> when I enter my credit card and they go into la-la land. And other
> nasty stuff.
>
> When I do visit my Win7 installation I don't care to have its Eudora
> download all the email that IT hasn't seen yet and I have to then sort
> it all out. It occured to me I might run another .bat file from XP
> into Win7's Eudora. When I'm in XP the Win7 install shows as D: in
> Windows Explorer. So:
> xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* D:\"Program
> Files (x86)"\Qualcomm\Eudora\mydata1\*.*
>
> After running this .bat I see the In.mbx of Win7's Eudora change to
> match the size (bytes)of the XP's Eudora, so the bat works.
>
> However, when I boot into Win7 and activate Eudora over there I don't
> see the same In.mbx that I copied over from XP. This Eudora chooses to
> only display the emails that it has downloaded off the server for
> itself.
>
> Xxcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* D:\"Program
> Files (x86)"\Qualcomm\Eudora\mydata1\*.*
>
> XP is 32 bit and Win7 is 64, but Eudora runs in Program Files (x86) so
> that shouldn't matter.
>
> Does anyone have a guess why Win7's Eudora is acting like this?

Think, for a moment, how an "Install for Everyone" program
wants to run.

Let's say John and Mary are alternate logins on the family computer.
When John logs in, he wants his own MBOX.

If each user had a "profile", and storage in

C:\users\John
C:\users\Mary

we could have private storage for each user.

*******

If instead, we store things in "C:\Program Files", then
unless there is a tree structure to sort the materials needed,
there will be trouble.

C:\Program Files is owned by TrustedInstaller, not by Administrator
and not by account John either.

*******

Well, you say, "I did it, and xcopy said it was fine".

Microsoft added a trick, and it works after a fashion.

https://social.technet.microsoft.com/Forums/en-US/f581b51e-fbe6-4ef5-b63d-f28945d12e1b/write-to-program-files-folder?forum=win10itprosecurity

"Applications written with the assumption that the user will
be running with administrator privileges experienced problems
in earlier versions of Windows when run from limited user
accounts, often because they attempted to write to machine-wide
or system directories (such as Program Files) or registry keys
(notably HKLM).

UAC attempts to alleviate this using File and
Registry Virtualization, which redirects writes (and subsequent
reads) to a per-user location within the user’s profile. For
example, if an application attempts to write to

"C:\program files\appname\settings.ini"

and the user doesn’t have permissions to write to that directory,
the write will get redirected to

"C:\Users\John\AppData\Local\VirtualStore\Program Files\appname\settings.ini".
"

That could be where the files went, on xcopy.

Now, the question would be, why doesn't Eudora see them when
account John is running the machine ? The virtualization is
supposed to work on reads too.

Using a good file search program like Agent Ransack, you
should take a look to see where the files got to. Did they
go to the VirtualStore path ? The VirtualStore path of
another user ? Or what ?

If you do the copy from *another OS*, that OS may not
know about this feature. The OS is tasked with implementing it.
WinXP for example, knows nothing about the user profile design
of Windows 7.

You have to be very careful with ownership issues, such that
files belonging to "John", don't suddenly become exclusive
to "Administrator" account. Doing Properties and using the
Security tab, can display some of these details.

Paul

What a bag of worms. And what a good explanation, I understood at
least 60% of it. It's pretty obvious now that I have to give up on
this project. I naively had thought there might be a fix by
manipulating Eudora somehow.
Thanks

On Fri, 10 Sep 2021 18:43:12 -0400, Paul <nospam@needed.invalid>
wrote:

>John B. Smith wrote:
>> I run a dual-boot (a microsoft freebie when I installed Win7 on top of
>> XP) and like it very much. I spend most of my time in XP, mostly
>> because all my software works here. More about that later. I have long
>> used a .bat file that runs on XP shutdown. Can't even remember how I
>> did that but it works. It uses
>> xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* etc
>> to copy all of Eudoras email mailboxes to a locaton on another
>> physical drive. If I have a catastrophe and have do a Macrium Image
>> Restore (from a week or so back) on my XP system, when it's done I use
>> another .bat file to copy the latest emails from that latest shutdown
>> back into my image-restored Eudora. It's always worked swell for me.
>>
>> Yes, Eudora email client is W-A-A-A-Y out of date but it is the best
>> email I've ever been able to find to fit my needs. A lot of people
>> still hang onto it, but the eudora newsgroup is not as savvy about all
>> computer stuff as this one.
>>
>> As time goes on I HAVE to spend more time in Win7 cause websites are
>> refusing to respond to my XP's Firefox. Or refuse to work right, like
>> when I enter my credit card and they go into la-la land. And other
>> nasty stuff.
>>
>> When I do visit my Win7 installation I don't care to have its Eudora
>> download all the email that IT hasn't seen yet and I have to then sort
>> it all out. It occured to me I might run another .bat file from XP
>> into Win7's Eudora. When I'm in XP the Win7 install shows as D: in
>> Windows Explorer. So:
>> xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* D:\"Program
>> Files (x86)"\Qualcomm\Eudora\mydata1\*.*
>>
>> After running this .bat I see the In.mbx of Win7's Eudora change to
>> match the size (bytes)of the XP's Eudora, so the bat works.
>>
>> However, when I boot into Win7 and activate Eudora over there I don't
>> see the same In.mbx that I copied over from XP. This Eudora chooses to
>> only display the emails that it has downloaded off the server for
>> itself.
>>
>> Xxcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* D:\"Program
>> Files (x86)"\Qualcomm\Eudora\mydata1\*.*
>>
>> XP is 32 bit and Win7 is 64, but Eudora runs in Program Files (x86) so
>> that shouldn't matter.
>>
>> Does anyone have a guess why Win7's Eudora is acting like this?
>
>Think, for a moment, how an "Install for Everyone" program
>wants to run.
>
>Let's say John and Mary are alternate logins on the family computer.
>When John logs in, he wants his own MBOX.
>
>If each user had a "profile", and storage in
>
> C:\users\John
> C:\users\Mary
>
>we could have private storage for each user.
>
>*******
>
>If instead, we store things in "C:\Program Files", then
>unless there is a tree structure to sort the materials needed,
>there will be trouble.
>
>C:\Program Files is owned by TrustedInstaller, not by Administrator
>and not by account John either.
>
>*******
>
>Well, you say, "I did it, and xcopy said it was fine".
>
>Microsoft added a trick, and it works after a fashion.
>
>https://social.technet.microsoft.com/Forums/en-US/f581b51e-fbe6-4ef5-b63d-f28945d12e1b/write-to-program-files-folder?forum=win10itprosecurity
>
> "Applications written with the assumption that the user will
> be running with administrator privileges experienced problems
> in earlier versions of Windows when run from limited user
> accounts, often because they attempted to write to machine-wide
> or system directories (such as Program Files) or registry keys
> (notably HKLM).
>
> UAC attempts to alleviate this using File and
> Registry Virtualization, which redirects writes (and subsequent
> reads) to a per-user location within the user’s profile. For
> example, if an application attempts to write to
>
> "C:\program files\appname\settings.ini"
>
> and the user doesn’t have permissions to write to that directory,
> the write will get redirected to
>
> "C:\Users\John\AppData\Local\VirtualStore\Program Files\appname\settings.ini".
> "
>
>That could be where the files went, on xcopy.
>
>Now, the question would be, why doesn't Eudora see them when
>account John is running the machine ? The virtualization is
>supposed to work on reads too.
>
>Using a good file search program like Agent Ransack, you
>should take a look to see where the files got to. Did they
>go to the VirtualStore path ? The VirtualStore path of
>another user ? Or what ?
>
>If you do the copy from *another OS*, that OS may not
>know about this feature. The OS is tasked with implementing it.
>WinXP for example, knows nothing about the user profile design
>of Windows 7.
>
>You have to be very careful with ownership issues, such that
>files belonging to "John", don't suddenly become exclusive
>to "Administrator" account. Doing Properties and using the
>Security tab, can display some of these details.
>
> Paul

John B. Smith wrote:
> What a bag of worms. And what a good explanation, I understood at
> least 60% of it. It's pretty obvious now that I have to give up on
> this project. I naively had thought there might be a fix by
> manipulating Eudora somehow.
> Thanks

You have to understand your "opponent" well, to make progress.
And I don't know Eudora, except for the name. It might be
a really old program, from before WinXP, and the program
might be assuming it's on a FAT32 partition.

If Eudora was in fact portable, you might stage all
the materials in a folder "owned by you". For example,
one day, on a machine with two C: partitions, I
tried executing Imgburn from the partition that
wasn't booted at the moment. And it worked! And that
is an example of a kind of proof that a program is
portable. The program in question, doesn't have to like that,
and in fact, selecting some option might even cause a failure,
but that's an example of discovering something will run without
being in a special place.

The permission issues can be overcome, with enough effort,
but doing this sort of thing is hardly an everyday method.
In this example, I was able to delete an EXE file from
a Program Files folder. The sequence, copies the TrustedInstaller
token, so that the program I want to run ("del") has the
authority of that account and can read or write as needed.

https://s22.postimg.cc/ktpilht29/elevate_to_trusted_installer.gif

If that virtualization folder existed, you could try XCopying
materials into there. Maybe that's enough. I don't know what
checks and balances the virtualization method uses, because
obviously if this was easy, malware would be doing it :-/

Paul

On 11/9/2021 5:43 AM, John B. Smith wrote:
> xcopy /D /Y c:\"Program Files"\Qualcomm\Eudora\mydata\*.* etc
> to copy all of Eudoras email mailboxes to a locaton on another

I would consider using robocopy.exe instead. You can do incremental
backups with it. You can also find out what files were changed before
actually running the command using option "/l".