Error installing a file

[Ed Dressel]

When installing on a Windows 10 computer a user is getting the following exception:

C:\Users\[User Name]\Documents\Trust Builders\Sample Import Data\Sample Life Insurance Import.xlsx

An error occurred while trying to rename a file in the destination directory:

MoveFile failed; code 5.

Access is denied.

It looks like they don't have rights, but that is their document directory. I am not sure I understand why they don't.

Ed Dressel

[Ed Dressel]

I got a chance to get on the computer and saw the problem every time. I could not get around it. The directory structure was created but no files were installed into the directory. I checked the security rights on the folder and didn't see anything that was strange. I skipped the three files that were to be installed into that folder and everythng else was okay.

The same user got the same error on both a Windows 10 and Windows 7 computer.

Any suggestions?

Ed Dressel

[Gavin Lambert]

On 22/07/2021 3:10 am, Ed Dressel wrote:
> I got a chance to get on the computer and saw the problem every time. I
> could not get around it. The directory structure was created but no
> files were installed into the directory. I checked the security rights
> on the folder and didn't see anything that was strange. I skipped the
> three files that were to be installed into that folder and everythng
> else was okay.
>
> The same user got the same error on both a Windows 10 and Windows 7
> computer.

If the installer is running as admin, then you should not install to the
{user*} directories, as you cannot reliably do so -- results will vary
depending whether the elevated user is the same as the original user or
not. Use the {common*} (or {auto*}) directories instead.

Otherwise, the two most likely culprits for this sort of thing are:

1. the file is already open in some application
2. the antimalware is blocking access, either due to some heuristic or
because it's just scanning the file too eagerly after the initial
install prior to the rename.

[Ed Dressel]

Thank you for your response.

> If the installer is running as admin, then you should not install 

> to the {user*} directories, as you cannot reliably do so 

I am not disagreeing with you, but I have done this for years on thousands of machines and never had a problem. 

> . 1. the file is already open in some application

The directory is empty--it created the directory, but there is nothing in it.

> 2. the antimalware is blocking access, either due to some heuristic

That sounds like the most likely cause, but when installing, I skip 3 files but everything else is installed correctly. The 3 files go into the user's "Dcouments\..." folder. 

Again, thank you for the response.

Ed

[Bill Stewart]

On Friday, July 23, 2021 at 8:26:26 AM UTC-6 Ed Dressel wrote:

> If the installer is running as admin, then you should not install 

> to the {user*} directories, as you cannot reliably do so 

I am not disagreeing with you, but I have done this for years on thousands of machines and never had a problem.

I suppose there's a first time for everything.

It's hard to suggest solutions without knowing precisely what your installer is doing and under what conditions.

[Gavin Lambert]

On 24/07/2021 2:26 am, Ed Dressel wrote:
> > If the installer is running as admin, then you should not install
> > to the {user*} directories, as you cannot reliably do so
>
> I am not disagreeing with you, but I have done this for years on
> thousands of machines and never had a problem.

It's very easy to demonstrate a problem with this.

1. Create a standard user account and log into it.
2. Run your installer and provide the credentials of the admin when
prompted (since the original user is not an admin).
3. Oops, you just installed files to the admin account, not the standard
account.

Things get even weirder than this on a corporate network that makes use
of roaming user profiles. (Which is less common these days, but is
likely to be getting more common again with the shift to emphasise
remote working and hot-desking.)