Limited user accounts on XP - can't even update files?

[gnznroses]

a few months ago when i was developing my program i was sure to test it under Limited accounts, and even the Guest account, and i had no problems. now, i'm not sure what has changed, but my program is unable to even update settings files in it's folder because Windows is denying it permission (i'm getting path/file access error).

i created a very simple test program to read/write text files and it has the same issue. i know there's gotta be a workaround because being unable to update settings files would make just about any program break. (and i know not all save all their settings in a My Docs subfolder)

any help is appreciated.

[dglienna]

Usually, you have settings in the app folder, or the registry, even.
Post some code. Hard to tell without seeing anything.

[gnznroses]

it actually is in the app folder - nowhere else. my program is ginormous but here's the test program i'd mentioned.

'start declarations for FileExists
Private Const INVALID_HANDLE_VALUE = -1
Public Const MAX_PATH = 260
Private Type FILETIME
dwLowDateTime As Long
dwHighDateTime As Long
End Type
Private Type SYSTEMTIME
wYear As Integer
wMonth As Integer
wDayOfWeek As Integer
wDay As Integer
wHour As Integer
wMinute As Integer
wSecond As Integer
wMilliseconds As Integer
End Type
Private Type WIN32_FIND_DATA
dwFileAttributes As Long
ftCreationTime As FILETIME
ftLastAccessTime As FILETIME
ftLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
dwReserved0 As Long
dwReserved1 As Long
cFileName As String * MAX_PATH
cAlternate As String * 14
End Type
Private Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileA" (ByVal lpFileName As String, lpFindFileData As WIN32_FIND_DATA) As Long
Private Declare Function FindClose Lib "kernel32" (ByVal hFindFile As Long) As Long
Private Declare Function FileTimeToSystemTime Lib "kernel32" (lpFileTime As FILETIME, lpSystemTime As SYSTEMTIME) As Long
Private Declare Function GetShortPathName Lib "kernel32" Alias "GetShortPathNameA" (ByVal lpszLongPath As String, ByVal lpszShortPath As String, ByVal cchBuffer As Long) As Long
Private Declare Sub GetSystemTime Lib "kernel32" (lpSystemTime As SYSTEMTIME)
' end declarations for FileExists



Public Function SaveTextToFile(FileFullPath As String, _
sText As String, Optional Overwrite As Boolean = True) As Boolean

'Purpose: Save Text to a file
'Parameters:
'-- FileFullPath - Directory/FileName to save file to
'-- sText - Text to write to file
'-- Overwrite (optional): If true, if the file exists, it
'is overwritten. If false,
'contents are appended to file
'if the file exists
'Returns: True if successful, false otherwise
'Example:
'SaveTextToFile "C:\My Documents\MyFile.txt", "Hello There"

On Error GoTo ErrorHandler

'check if dir exists, if not, make it
Dim dirend As Long
Dim thepathname As String
dirend = InStrRev(FileFullPath, "\")
thepathname = Left$(FileFullPath, dirend - 1)
If DirExists(thepathname) = False Then
MkDir thepathname
End If

Dim iFileNumber As Long
iFileNumber = FreeFile

If Overwrite Then
Open FileFullPath For Output As #iFileNumber
Else
Open FileFullPath For Append As #iFileNumber
End If

Print #iFileNumber, sText;
SaveTextToFile = True

ErrorHandler:
Close #iFileNumber
End Function


Public Function FileExists(sSource As String) As Boolean
Dim WFD As WIN32_FIND_DATA
Dim hFile As Long

hFile = FindFirstFile(sSource, WFD)
FileExists = hFile <> INVALID_HANDLE_VALUE

Call FindClose(hFile)
End Function

Public Function DirExists(strDir As String) As Boolean
On Error GoTo PROC_ERR

DirExists = Len(Dir$(strDir & "\.", vbDirectory)) > 0

PROC_EXIT:
Exit Function
PROC_ERR:
MsgBox "Error: " & Err.Number & ". " & Err.Description, , "DirExists"
Resume PROC_EXIT
End Function








Public Function ReadTxtFile(FileName$, Optional NoErrors As Boolean) As String
Dim tmpLine$
Dim fnum As Long
Dim flen As Long
Dim txt As String
On Error GoTo ErrorHandler

fnum = FreeFile
Open FileName$ For Input As fnum
txt = Input$(LOF(fnum), #fnum)
Close #fnum
ReadTxtFile = txt
Exit Function
ErrorHandler:
Close #fnum
If NoErrors = True Then Exit Function
Dim bFileExists As Boolean
bFileExists = FileExists(FileName$)
If bFileExists = False Then
MsgBox FileName$ & " not found.", vbApplicationModal + vbOKOnly, "ReadTxtFile"
Else
MsgBox FileName$ & " is not composed of text.", vbApplicationModal + vbOKOnly, "ReadTxtFile"
End If
End Function

Private Sub Command1_Click()
SaveTextToFile App.Path & "\new.dat", "newwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwwww"
End Sub

Private Sub Command2_Click()
SaveTextToFile App.Path & "\existing.dat", Text2.Text
End Sub

Private Sub Command3_Click()
Text1.Text = ReadTxtFile(App.Path & "\new.dat")
End Sub

Private Sub Command4_Click()
Text1.Text = ReadTxtFile(App.Path & "\existing.dat")
End Sub

writing files returns error 70: path/file error (forget the exact text of it).
of course it works OK under an admin account.

looking back through my emails i had someone report this problem with my program a long time ago. i had ran further tests at that time and was still unable to reproduce it. so i'm not sure why i have trouble now. i knew limited accounts couldn't install to Program Files, but it always would let the program update it's own settings, once the app had been installed.

[dglienna]

Comment out your error traps. Odd that you are still getting a 70 with trapping. Might have missed something.

Sure nothing is under the admin's folder?

[gnznroses]

oh, yeah in the sample app you don't get any msgbox about the error, and the app doesn't crash, because the error handling in it simply exits the function. so it doesn't actually display the error 70, i just meant that that's which error is occuring to prevent the program from working. when you click the buttons to save data you don't actually see anythign at all happen.

[LaVolpe]

If you interpret this page from MSDN as I did, then users may not have privileges to write in the Program Files folders/subfolders.

Excerpt follows:
On an NTFS-based Windows XP system, users with least-privileged user accounts have only limited access to several folders. However, they would have complete access on a FAT32-based Windows XP system.

The following table lists the default location of these folders and their permissions.

Path & Folder Contents - Access (RWD=read/write/delete)
<Drive>:\Windows The Windows operating system - Read
<Drive>:\Program Files Executable application files - Read
<Drive>:\Documents and Settings\Username* Each user's files - RWD
<Drive>:\Documents and Settings\All Users All user files - RWD

* Username is the user's login name.

In a least-privileged user account, you may read, write, create and delete files in either folder: Documents and Settings\Username or Documents and Settings\All Users.

What this means is that you should not place save games in \Program Files, instead they should go in a sub-folder in \My Documents. Also you should not place temporary application data in \Program Files or \My Documents, instead it should be placed in Application Data folder (CSIDL_LOCAL_APPDATA).

[gnznroses]

oh, that explains it my old computer was FAT32...

i also figured out to use a subfolder of All Users\Application Data. seems to work fine. (now i need to test the equivalent on Vista)

[gnznroses]

i thought my problem was solved but it's not. again, it works fine under an admin account. but here is what i found out:
if i log in to a standard account, and those files have not yet been created (in
Documents and Settings\All Users\Application Data\file test), everything works fine. i can both read and write. but if i use the admin account first, and create those files with the test app, when i log into the standard account, it can read em but not write to em. i guess thye become owned by the admin and so can't be modified by anyone else. how can i fix this?

[LaVolpe]

Don't think you can per se. NT security should prevent anyone from modifying or deleting another user's files unless logged in with Admin rights or ownership rights. Suggest saving the file under the current logged in user's Application Data folder or looking for ways of giving the Everyone account read-write-modify/delete permissions on that file?

[gnznroses]

yeah, if it's created under Limited Account #1, it can't be written by Limited Account #2. it can of course still be written by an admin.
i thought that was the whole point of the All Users folder... so i guess there is nowhere i can save settings where all users can modify them. that's just dumb.

it should be possible to give all users write access to a folder but i dunno how to do it in-code. and i also wonder if XP Home could do it at all, since it has simplified security settings in regards to ownership/sharing of files.

[LaVolpe]

I'll do some looking around. My thoughts are this... When the app is run, the first time it creates & saves the file, the app should apply full control to "Everyone". This way, when it is run again (say by a different user), then the file can be deleted & recreated as needed, of course applying full control to everyone again. This is relatively easy to do manually, but I haven't needed to do it thru code. Research needed. API method? command line method?

[LaVolpe]

See if this link helps. The examples are in .NET, but using for VB should be doable. I have not looked too deeply into the example(s) so I can't vouch for them. Looks like a lot of code for such a small task. But to quote one security officer I know: Greater security = greater inconvenience.

[gnznroses]

thanks for the help. it sounds like it may just work. i'll see if i can translate that into vb6...

[dglienna]

The Admin account can then set the folder permissions, to override to Everyone.

I've posted about the CACLS /? command...