Not your typical get(temporarypath) problem

[ddreese]

Short version:

Where EXACTLY does Filemaker pull the system temporary path from in Windows 7? A preference file stashed away somewhere? Registry entry?

Problem:

SOME users cannot save .PDF files to disk either in a script or manually. We get the error "... could not be created on this disk. use a different name, make more room on the disk, unlock it or use a different disk."

It appears that even if you're not saving a .PDF in a script (File -> Save/Send Records As -> PDF) it still uses the temporary path used in get(temporarypath) to save the file to first, that's all I can guess. For the users that it doesn't work, their path is resolving to /C:/TEMP/S## whereas the users that it does work it resolves to the correct /C:/Users/USERNAME/local/appdata/S##.##

The only difference between the users who it does work and it doesn't is what their get(temporarypath) resolves to. They use the same privilege groups inside filemaker, same operating systems, same computer-level privileges.

What I've tried:

• Uninstall/reinstall of FM11
  
• Confirmed windows TEMP and TMP environmental variable paths to be correct
  
• Searched registry for C:\TEMP
  
• Looked through the /local/AppData folders to try and find a filemaker file that sets user preferences
  

Additional thoughts:

Our best guess is that there is something weird happening when we run the Windows migration tool to export staff's profile information in preparation of getting their new Windows 7 machine. Some sort of preference file being saved or something. Whatever it is, I'm going nuts.

[bcooney]

This could be a permissions issue. Have a user create a text file on the Desktop. Can they? If so, have them Save as PDF to the Desktop. Be sure that they do not have a file with the same name already created and open.

Otherwise, this is usually the sign of an improper path definition.

FMI Help Get (TemporaryPath) clearly explains the function.

[Vaughan]

AFAIK the temporary folder is randomly named, created at the beginning of the FMP session and deleted at the end. The folder may change each time the function is used, but this should not matter because it is an implementation detail and not important to using the function.

[ddreese]

Well we found out how to fix it, but not why it "breaks"

bcooney - To answer your question yes users could create files in their normal daily use of the computer outside of filemaker.

As I've said before the problem appears to happen somehow in the USMT (User state migration tool?) process copying the profile. The solution to the problem is making sure the specific user is the owner with full access to their profile, where as previously "system" was the owner, which is the default. Re-assigning the owner shows a lot of warnings for .tmp files that it can't change the permission status but a simple logoff and logon then changes it.

My best guess was there some weird creation/write permissions error when filemaker loads up that it can't create the temp folder as defined by the OS and then it would create the temporary path at c:\TEMP instead?

Step by step:

Login to windows with admin access

Browse to C:\Users

Open properties for specific profile

Security tab -> Advanced button

Owner tab -> Edit button -> Other users or groups -> Enter users account

Make sure you select the "Replace owner on subcontainers and objects" box, Click ok. You may get a bunch of permission errors, click through them.

Login as user, should be working fine.

Disclaimer: I have no idea what this may screw up by doing this but it worked for us.