[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

file and folder permissions

Mike Williams

8/28/2010 4:12:00 PM

Being a hobbyist I don't often get involved with file permissions when my
code is run on other machines. I do know a few things about it, for example
the behaviour of code running in a folder in the main Program Files folder
and how it interacts with the current user's VirtualStore folder, but that's
about all I know and I'd appreciate a little help on a specific matter.

I know about it normally being best to write user data files only to the
current user's data folder (for which I would use CSIDL_LOCAL_APPDATA), but
I have written a little VB6 program that is intended to be run direct from a
memory stick (one that users can run from direct from a memory stick on
their own machines) and so I need to create new files and modify existing
data files so that the data "moves with the stick", so to speak. This is not
in a corporate environment and so I cannot use the "Roaming" stuff. The way
I am handling it at the moment is to write my data files either directly
into App.Path or into a folder I create at runtime within App.Path, where
App.Path would normally be my program's folder on the memory stick. I've
tried this out on all the standard available accounts (Administrator,
Standard User and Guest Account) on both Vista and windows 7 and it works
fine, but I'm wondering if there are any "gotchas" that I haven't
considered, and whether I am okay to do this?

The same method also works if the user copies my app folder from the memory
stick onto his Desktop, which I sort of half expected it to seeing as the
Desktop is a child of the current user's "User" folder, and although the
user would probably not do that and would run it directly from the stick I
am wondering if he would be okay doing it (copying the app folder to the
desktop and running it there and then copying the app folder back to the
stick or emailing it on somewhere or whatever)?

I do realise that, depending on the type of account he is running, he is
going to have problems if he copies the app folder anywhere else on his
machine and runs it from there, but that is not really a problem because the
users will be told never to do that (the general idea, which is in fact
exactly what they want, is that they run the program direct from a memory
stick, and then take the program and any data it creates with them (on the
stick) so that they can run the same program with the same modified data on
any other machine. I think this will probably work on all current machines
XP and upwards because the VB6 runtime is usually present by default on such
machines, and I am dealing with any extra controls or libraries my program
needs by using a manifest to use them directly from the app's own folder
without installing or registering them.

Anyway, this all works fine as far as I have tested it so far, but I'm
wondering if I am doing this correctly, or are there perhaps any problems I
am likely to run into, things that I might not have considered?

Mike
49 Answers

Woodie Morris

8/29/2010 3:33:00 AM

0

Just a thought, maybe your app would be more susceptible to getting infected
by a virus since it's an executable residing in a folder that needs no
permission elevation to be written to. How big of a deal that is I don't
know.

-Woodie


"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:i5bcg0$jqb$1@speranza.aioe.org...
> Being a hobbyist I don't often get involved with file permissions when my
> code is run on other machines. I do know a few things about it, for
> example the behaviour of code running in a folder in the main Program
> Files folder and how it interacts with the current user's VirtualStore
> folder, but that's about all I know and I'd appreciate a little help on a
> specific matter.
>
> I know about it normally being best to write user data files only to the
> current user's data folder (for which I would use CSIDL_LOCAL_APPDATA),
> but I have written a little VB6 program that is intended to be run direct
> from a memory stick (one that users can run from direct from a memory
> stick on their own machines) and so I need to create new files and modify
> existing data files so that the data "moves with the stick", so to speak.
> This is not in a corporate environment and so I cannot use the "Roaming"
> stuff. The way I am handling it at the moment is to write my data files
> either directly into App.Path or into a folder I create at runtime within
> App.Path, where App.Path would normally be my program's folder on the
> memory stick. I've tried this out on all the standard available accounts
> (Administrator, Standard User and Guest Account) on both Vista and windows
> 7 and it works fine, but I'm wondering if there are any "gotchas" that I
> haven't considered, and whether I am okay to do this?
>
> The same method also works if the user copies my app folder from the
> memory stick onto his Desktop, which I sort of half expected it to seeing
> as the Desktop is a child of the current user's "User" folder, and
> although the user would probably not do that and would run it directly
> from the stick I am wondering if he would be okay doing it (copying the
> app folder to the desktop and running it there and then copying the app
> folder back to the stick or emailing it on somewhere or whatever)?
>
> I do realise that, depending on the type of account he is running, he is
> going to have problems if he copies the app folder anywhere else on his
> machine and runs it from there, but that is not really a problem because
> the users will be told never to do that (the general idea, which is in
> fact exactly what they want, is that they run the program direct from a
> memory stick, and then take the program and any data it creates with them
> (on the stick) so that they can run the same program with the same
> modified data on any other machine. I think this will probably work on all
> current machines XP and upwards because the VB6 runtime is usually present
> by default on such machines, and I am dealing with any extra controls or
> libraries my program needs by using a manifest to use them directly from
> the app's own folder without installing or registering them.
>
> Anyway, this all works fine as far as I have tested it so far, but I'm
> wondering if I am doing this correctly, or are there perhaps any problems
> I am likely to run into, things that I might not have considered?
>
> Mike
>
>

F*CK

8/29/2010 3:44:00 AM

0

Even a guest account have full access to Flash Drives since most of these
drives/cards are FAT32 formatted. Only Vista and above can format flash
drives to NTFS.


"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:i5bcg0$jqb$1@speranza.aioe.org...
| Being a hobbyist I don't often get involved with file permissions when my

(nobody)

8/29/2010 8:42:00 AM

0

"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:i5bcg0$jqb$1@speranza.aioe.org...
> Being a hobbyist I don't often get involved with file permissions when my
> code is run on other machines. I do know a few things about it, for
> example the behaviour of code running in a folder in the main Program
> Files folder and how it interacts with the current user's VirtualStore
> folder, but that's about all I know and I'd appreciate a little help on a
> specific matter.
>
> I know about it normally being best to write user data files only to the
> current user's data folder (for which I would use CSIDL_LOCAL_APPDATA),
> but

"Never" use CSIDL_LOCAL_APPDATA for settings, use CSIDL_APPDATA instead(if
you want to), along with CSIDL_FLAG_CREATE because the folder doesn't
necessarily exits, especially after a clean install, or after creating a new
user. This would work fine whether roaming is enabled or not. The "only"
legitimate use for CSIDL_LOCAL_APPDATA is for large files, like Temp files,
and a lot of email messages.

When a user logs in or out when roaming is enabled, his profile is
downloaded/uploaded to/from a server, except for what's in
CSIDL_LOCAL_APPDATA, so basically the user sees his documents and desktop
regardless of which computer he uses. HKEY_CURRENT_USER is a actually stored
in a file called "ntuser.dat", which is in the user's home folder, so this
get uploaded/downloaded too. This file is generally located in this
location:

XP: C:\Documents and Settings\<USERID>\ntuser.dat
Vista+: C:\Users\<USERID>\NTUSER.DAT

It's not necessarily mapped into HKEY_USERS.

> Anyway, this all works fine as far as I have tested it so far, but I'm
> wondering if I am doing this correctly, or are there perhaps any problems
> I am likely to run into, things that I might not have considered?

One thing that could bring a source of confusion to the user is when the
user uses one of the protected locations, and the settings file get
redirected elsewhere(In Vista+), so when the user copies back to the stick
again, he finds that the old settings where used. To force Vista+ to return
"Access is denied" to your app and stop redirecting, add asInvoker manifest
to your EXE. For example, if at startup you use WritePrivateProfileString()
to test if the INI file is writable, it would fail, and Err.LastDLLError
would be 5(ERROR_ACCESS_DENIED), so you can warn the user to choose another
location before using the program, or proceed anyway(in case the PC is
locked down by some software). Here is a function that you can use to test
if the file is writable(air code):

Public Function IsWritable(ByRef sFullFileName As String) As Boolean
Dim f As Long

On Error Resume Next

f = FreeFile
Open sFullFileName For Binary Access Read Write Shared As f
If Err.Number <> 0 Then
IsWritable = False
GoTo ExitSub
End If
Close f


IsWritable = True

ExitSub:
Err.Clear
End Function

Mike Williams

8/30/2010 6:25:00 AM

0

"Abhishek" <user@server.com> wrote in message
news:i5cl21$kt6$1@speranza.aioe.org...

> Even a guest account have full access to Flash Drives since
> most of these drives/cards are FAT32 formatted. Only
> Vista and above can format flash drives to NTFS.

Thanks. In this specific case very few USB sticks will be NTFS, and
virtually all machines will be XP or later anyway, so it should be fine. I
had already considered the NTFS thing and what I was after was information
as to whether any account on any system might possibly be configured to
disallow writing to removeable drives, but judging by the tone of your
answer I assume that will not be a problem. Thanks again.

Mike

Mike Williams

8/30/2010 7:34:00 AM

0

"Nobody" <nobody@nobody.com> wrote in message
news:i5d6hg$ffu$1@speranza.aioe.org...

> "Never" use CSIDL_LOCAL_APPDATA for settings,
> use CSIDL_APPDATA instead(if you want to), along
> with CSIDL_FLAG_CREATE. This would work fine
> whether roaming is enabled or not. The "only" legitimate
> use for CSIDL_LOCAL_APPDATA is for large files,
> like Temp files, and a lot of email messages. When a
> user logs in or out when roaming is enabled, his profile
> is downloaded/uploaded to/from a server, except for
> what's in CSIDL_LOCAL_APPDATA, so basically
> the user sees his documents . . .

Thanks for the information. In this scenario the roaming advantage of
CSIDL_APPDATA for settings and other data will actually not be of any use to
me because it will not normally be run on networked systems and even if it
does happen to be run on one or more networked machines they will not
necessarily be on the same network. That's why I am saving all settings and
all other permanent data the app produces to the App's path on the USB
stick.

I'll be using the CSIDL_LOCAL_APPDATA purely for temporary files, of which
there may be many. I need to use the main drive for my temporary files
because some users will have fairly low capacity USB sticks which might not
have a great deal of spare space. Most of these machines will be simple home
setups, perhaps running various different types of account, and also a
number of machines at a computer club that may or may not be networked, and
I was wondering about whether there may be some machines that might not
permit writing to either the USB memory stick or the CSIDL_LOCAL_APPDATA
folder. From the general tone of your answer may I assume that will not be a
problem?

This is actually for a friend on the other side of "the big pond" and so I
am not physically able to look at his various setups, but I do know that
some of the machines will be running Deep Freeze and I'll look into that
aspect later. At the moment I'm assuming that will not present a problem
because as far as I know systems such as Deep Freeze permit all the normal
system drive writes that are normally available but just direct them to a
different partition so that the main partition remains intact and unaltered
and is clean at the next bootup. I'm fairly sure there will not be a problem
there otherwise such systems would be effectively unusable.

> along with CSIDL_FLAG_CREATE because
> the folder doesn't necessarily exits

Thanks a lot for that one. I never considered the possibility that some
folders such as CSIDL_APPDATA might not actually exist. I'm not sure whether
that also applies to the CSIDL_LOCAL_APPDATA but I'll add the CREATE flag
anyway just in case.

Thanks again.

Mike

Mike Williams

8/30/2010 9:27:00 AM

0

"Nobody" <nobody@nobody.com> wrote in message
news:i5d6hg$ffu$1@speranza.aioe.org...

> . . . use CSIDL_APPDATA instead along
> with CSIDL_FLAG_CREATE . . .

I've just tried that, both with CSIDL_APPDATA and with CSIDL_LOCAL_APPDATA
and with various others and when I include the flag, as in CSIDL_APPDATA Or
CSIDL_FLAG_CREATE (both Longs) the call to SHGetSpecialFolderLocation fails,
so I do not get the folder location at all. It works fine without the flag,
but it fails with it. This is on an Admin Account in Widows Vista, and it
still fails even if I run the compiled exe "As Admin". Any idea why it may
be failing? I would have thought that if you include the flag and if the
folder already exists then you would still get the folder location anyway.
Is that not the case?

I know that SHGetSpecialFolderLocation was superseded by something else from
Win2K onwards (can't remember what it is and I can't get to MSDN right now)
but I believe it has been included for backwards compatibility and it still
works on XP and Vista and Win7. It certainly works okay in Vista without the
CSIDL_FLAG_CREATE flag, but not with it. For some strange reason I cannot
get any MSDN pages at the moment, no matter what page I look for, so if
anybody knows what has replaced SHGetSpecialFolderLocation and especially if
they have any sample code then it would be very much appreciated. I'm not
sure yet what is preventing me from viewing the MSDN help pages, but if for
example I enter the following, which the page I want:

http://www.msdn.microsoft.com/en-us/librar...(VS.85).aspx

.. . . I do get an MSDN page but it is just generic and it tell me that it is
"Unable To Service Request". This happens whatever MSDN help page I look
for. It is beginning to look as though the MSDN help pages are deliberately
being blocked. In fact I seem to recall reading somewhere that this is what
happens if MS thinks that a specific system is not running a genuine and
fully activated version of Windows, which definitely is not the case here
because my system is perfectly kosher and in in any case I've had this
system for years and this problem only started today (or perhaps in the last
week or so). The one thing I have installed recently, just a few days ago,
is Norton Internet Security 2010, which I suspect may be the culprit, but
I've checked Norton's settings and firewall settings and my own Internet
settings and I cannot see anything obvious. I wonder if Norton has made some
changes to my system that is causing MS to believe that it is a different
system and that it is no longer "kosher"? Has anybody else come across
similar problems?

Mike

F*CK

8/30/2010 10:25:00 AM

0

Writing to removable drives can be disabled using registry, its not
dependent on user account type. I have seen a few company provided laptops
with standard user account and writing to removable drives disabled. which
the user easy enabled using a reg fix :)

If I were you and have to save settings for my portable app, then I would
first try app.path, if not then appdata, if still not then temp folder with
a warning to user.

You may also try to launch the application as admin. for that make a small
loader/welcome app with open to open you app, check if user is admin then
try to shell the main app. here you can ask the user where to save the
settings, so he will automatically takes care of his flash drive. and any
errors then will be by-design and responsibility of user :P


"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:i5fisj$f73$1@speranza.aioe.org...
| "Abhishek" <user@server.com> wrote in message
| news:i5cl21$kt6$1@speranza.aioe.org...
|
| as to whether any account on any system might possibly be configured to
| disallow writing to removeable drives, but judging by the tone of your
| answer I assume that will not be a problem. Thanks again.
|
| Mike
|


Mike Williams

8/30/2010 10:51:00 AM

0

"Abhishek" <user@server.com> wrote in message
news:i5g0st$5fh$1@speranza.aioe.org...

> Writing to removable drives can be disabled using registry,
> its not dependent on user account type. I have seen a few
> company provided laptops with standard user account and
> writing to removable drives disabled. which the user easy
> enabled using a reg fix :) If I were you and have to save
> settings for my portable app, then I would first try app.path,
> if not then appdata, if still not then temp folder with a
> warning to user.

Thanks. In this particular case it is essential that the settings and lots
and lots of other user created data is saved to the USB stick from which
they normally run the app, since that is how users normally transport the
app and its data around so that they can use it in its current state on any
other machine, wherever that machine may be. I think in some cases they copy
the app folder from the USB stick onto their desktop and run it from there,
and then finally transfer it back to the USB stick when they are happy with
what they have done (this is for a friend on the other side of "the big
pond" and so I don't have much control over what they actually do). If
writing to a USB stick is disabled on a specific machine then I'm assuming
that they will not be able to copy their folder from the desktop onto it
either, so in that case they would be hosed. Actually I very much doubt that
writing to USB stick will be disabled on any of the machines (none of them
are the sort of machines you mentioned) but if there are any then I will
advise them to re-enable it.

Thank you.

Mike

F*CK

8/30/2010 11:20:00 AM

0

http://vbnet.mvps.org/index.html?code/network/isusera...

here is it. say thanks to Randy Birch (click an ad below)


"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:i5g2dk$8au$1@speranza.aioe.org...
| "Abhishek" <user@server.com> wrote in message
| news:i5g0st$5fh$1@speranza.aioe.org...
|
| > Writing to removable drives can be disabled using registry,
| > its not dependent on user account type. I have seen a few
| > company provided laptops with standard user account and
| > writing to removable drives disabled. which the user easy
| > enabled using a reg fix :) If I were you and have to save
| > settings for my portable app, then I would first try app.path,
| > if not then appdata, if still not then temp folder with a
| > warning to user.


Mayayana

8/30/2010 1:11:00 PM

0

Just curious...Is there a reason to look for
the path of local app data\TEMP rather than just
calling GetTempPath?

I've noticed that there are a lot of TEMP
folders on XP. I wrote a Desktop script to clean
out TEMP files and found 6 locations that I need
to check! But I don't get why any software would
actually target anything other than %TEMP%. Why
not just let Windows sort it out and give you the
best path?