|
code
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
file and folder permissionscode 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 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 Show quoteHide quote "Mike Williams" <M***@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 > > 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. Show quoteHide quote "Mike Williams" <M***@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 "Abhishek" <u***@server.com> wrote in message Thanks. In this specific case very few USB sticks will be NTFS, and 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. 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 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 Show quoteHide quote "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message news:i5fisj$f73$1@speranza.aioe.org... | "Abhishek" <u***@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 | "Abhishek" <u***@server.com> wrote in message Thanks. In this particular case it is essential that the settings and lots 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. 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
http://vbnet.mvps.org/index.html?code/network/isuseranadmin.htm
here is it. say thanks to Randy Birch (click an ad below) Show quoteHide quote "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message news:i5g2dk$8au$1@speranza.aioe.org... | "Abhishek" <u***@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. "Abhishek" <u***@server.com> wrote in message That returns False for all acounts on my Vista machine, including the normal news:i5g43t$ase$1@speranza.aioe.org... > here is it [to determine whether user is admin]. > say thanks to Randy Birch > http://vbnet.mvps.org/index.html?code/network/isuseranadmin.htm > main Admin Account. In Vista it seems to be detecting whether the code is currently running under elevated privileges, because if you create an exe of it and right click the exe and select "Run as Admin" then it does then True. Mike go to this page, here u will find a reg file to enable/disable write access
to usb drives. http://www.veign.com/downloads.php Show quoteHide quote "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message news:i5gij5$63v$1@speranza.aioe.org... | "Abhishek" <u***@server.com> wrote in message | news:i5g43t$ase$1@speranza.aioe.org... | > here is it [to determine whether user is admin]. | > say thanks to Randy Birch | > http://vbnet.mvps.org/index.html?code/network/isuseranadmin.htm | > | | That returns False for all acounts on my Vista machine, including the normal | main Admin Account. In Vista it seems to be detecting whether the code is | currently running under elevated privileges, because if you create an exe of | it and right click the exe and select "Run as Admin" then it does then True. | | Mike | Abhishek formulated the question :
> Only Vista and above can format flash drives to NTFS. I'm pretty darned sure I've ran convert against those in XP, and ended up with NTFS sticks? C:\>convert /? Converts a FAT volume to NTFS. CONVERT volume /FS:NTFS [/V] [/CvtArea:filename] [/NoSecurity] [/X] volume Specifies the drive letter (followed by a colon), mount point, or volume name. /FS:NTFS Specifies that the volume will be converted to NTFS. /V Specifies that Convert will be run in verbose mode. /CvtArea:filename Specifies a contiguous file in the root directory that will be the place holder for NTFS system files. /NoSecurity Specifies that the security settings on the converted files and directories allow access by all users. /X Forces the volume to dismount first if necessary. All open handles to the volume will not be valid. C:\> Can be done using 3rd party tools tool, but most people dont know about it,
and consumers dont use cmd line tools. Show quoteHide quote "Karl E. Peterson" <k***@exmvps.org> wrote in message news:i5mo8m$16b$1@news.eternal-september.org... | Abhishek formulated the question : | > Only Vista and above can format flash drives to NTFS. | Abhishek explained :
> Can be done using 3rd party tools tool, but most people dont know about it, Are you sure about your claim? I'm pretty sure that I was able to > and consumers dont use cmd line tools. > format my flash drive using ntfs on xp... And not from the commandline either. Yeah, thought so: http://www.online-tech-tips.com/computer-tips/format-usb-ntfs/ -- Tom Shelton | > Can be done using 3rd party tools tool, but most people dont know about Even if that's true, what's the point? Couldn'tit, | > and consumers dont use cmd line tools. | > | | Are you sure about your claim? I'm pretty sure that I was able to | format my flash drive using ntfs on xp... And not from the commandline | either. | anyone access it on any PC where they have admin rights? In any case, Abhishek is right: Very few people ever change defaults, and those who do know what they're doing. on 9/1/2010, Mayayana supposed :
Show quoteHide quote >>> Can be done using 3rd party tools tool, but most people dont know about I was responding to the "Can be done using 3rd party tools" - which >>> it, and consumers dont use cmd line tools. >>> >> >> Are you sure about your claim? I'm pretty sure that I was able to >> format my flash drive using ntfs on xp... And not from the commandline >> either. >> > > Even if that's true, what's the point? Couldn't > anyone access it on any PC where they have > admin rights? In any case, Abhishek is right: > Very few people ever change defaults, and those > who do know what they're doing. isn't true. XP is perfectly capable of formating removable media as NTFS without 3rd party tools, from the standard UI interface... Wether or not you think there is a point in actually doing so is not the issue. -- Tom Shelton
Show quote
Hide quote
| >> Are you sure about your claim? I'm pretty sure that I was able to I understood what you were addressing. You think| >> format my flash drive using ntfs on xp... And not from the commandline | >> either. | >> | > | > Even if that's true, what's the point? Couldn't | > anyone access it on any PC where they have | > admin rights? In any case, Abhishek is right: | > Very few people ever change defaults, and those | > who do know what they're doing. | | I was responding to the "Can be done using 3rd party tools" - which | isn't true. XP is perfectly capable of formating removable media as | NTFS without 3rd party tools, from the standard UI interface... | | Wether or not you think there is a point in actually doing so is not | the issue. | you remember formatting to NTFS with Windows tools. But does it matter? I was actually curious whether there might be a point that I haven't thought of. Two of you say you've formatted sticks to NTFS, so maybe there was some reason to do that. But I can't think of what it might be. I assume it would be accessible to everyone as admin and to no one as less than admin. If you want it to be NTFS then I assume that you're an NTFS lover who tries to run with limited rights whenever possible. So it's a hassle for you to access the stick but anyone else who wants to access it can do so by just running as admin. I don't get it. Mayayana laid this down on his screen :
Show quoteHide quote >>>> Are you sure about your claim? I'm pretty sure that I was able to I believe the main reason I did so, was that I remember reading that >>>> format my flash drive using ntfs on xp... And not from the commandline >>>> either. >>>> >>> >>> Even if that's true, what's the point? Couldn't >>> anyone access it on any PC where they have >>> admin rights? In any case, Abhishek is right: >>> Very few people ever change defaults, and those >>> who do know what they're doing. >> >> I was responding to the "Can be done using 3rd party tools" - which >> isn't true. XP is perfectly capable of formating removable media as >> NTFS without 3rd party tools, from the standard UI interface... >> >> Wether or not you think there is a point in actually doing so is not >> the issue. >> > > I understood what you were addressing. You think > you remember formatting to NTFS with Windows > tools. But does it matter? > > I was actually curious whether there might be > a point that I haven't thought of. Two of you > say you've formatted sticks to NTFS, so maybe > there was some reason to do that. But I can't think > of what it might be. I assume it would be accessible > to everyone as admin and to no one as less than admin. > > If you want it to be NTFS then I assume that you're > an NTFS lover who tries to run with limited rights > whenever possible. So it's a hassle for you to access > the stick but anyone else who wants to access it can > do so by just running as admin. I don't get it. you can actually fit more files on the disk with NTFS... Other then that, because I could :) -- Tom Shelton "Mayayana" <mayayana@invalid.nospam> wrote in message Well 8GB and 16GB USB sticks are very cheap these days, and lots of people news:i5n6el$l7s$1@news.eternal-september.org... > > I was actually curious whether there might > be a point that I haven't thought of. Two of > you say you've formatted sticks to NTFS, > so maybe there was some reason to do that. > But I can't think of what it might be. create or edit videos, and if they end up with a video (or any other very large file) that is more than 4GB in size then they will not be able to save it as a single file onto a FAT32 stick. Mike Mayayana wrote:
> I regularly do Robocopy incremental backups of trees that can run to> If you want it to be NTFS then I assume that you're > an NTFS lover who tries to run with limited rights > whenever possible. So it's a hassle for you to access > the stick but anyone else who wants to access it can > do so by just running as admin. I don't get it. hundreds of directories with 1000+ files, to USB sticks. The write process is fairly slow, so incremental works well because there are few changes. All the sources are on NTFS or network drives. Twice a year, when daylight time switches, RoboCopy will completly rewrite the entire tree, taking hours, if the stick is formatted FAT32. That's because FAT32 doesn't use UTC filetimes. Switching to NTFS eliminates that hassle. So there's at least one solid reason to use NTFS on thumb drives. Mayayana has brought this to us :
> If you want it to be NTFS then I assume that you're Nope. NTFS supports files >2GB and FAT32 doesn't. That simple.> an NTFS lover who tries to run with limited rights > whenever possible. "Karl E. Peterson" <k***@exmvps.org> wrote in message Actually, like I said in my earlier reply to Mayayana, that's 4GB, but it news:i5orao$4rj$1@news.eternal-september.org... >> Mayayana has brought this to us : >> If you want it to be NTFS then I assume that you're >> an NTFS lover who tries to run with limited rights >> whenever possible. > > Nope. NTFS supports files >2GB and FAT32 doesn't. That simple. certainly is a major limitation of FAT32 these days when lots of people create files larger than that on a daily basis. What a change from when I was a lad, when a 40KB file would have been regarded as almost impossibly large ;-) Mike Mike Williams used his keyboard to write :
> "Karl E. Peterson" <k***@exmvps.org> wrote in message Huh. I coulda swore it as 2gb. Looks like you're right!> news:i5orao$4rj$1@news.eternal-september.org... > >>> Mayayana has brought this to us : >>> If you want it to be NTFS then I assume that you're >>> an NTFS lover who tries to run with limited rights >>> whenever possible. >> >> Nope. NTFS supports files >2GB and FAT32 doesn't. That simple. > > Actually, like I said in my earlier reply to Mayayana, that's 4GB, but it > certainly is a major limitation of FAT32 these days when lots of people > create files larger than that on a daily basis. > What a change from when I was a lad, when a 40KB file would have been Heh, if your "drive" was only 160kb, hellyeah! <g>> regarded as almost impossibly large ;-) On Thu, 02 Sep 2010 13:29:48 -0700, Karl E. Peterson <k***@exmvps.org>
wrote: >Heh, if your "drive" was only 160kb, hellyeah! <g> Drive? You mean cards, right? Paper cards? Fortunately I missedthe era of paper tape. Tony -- Tony Toews, Microsoft Access MVP Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/ For a convenient utility to keep your users FEs and other files updated see http://www.autofeupdater.com/ on 9/6/2010, Tony Toews supposed :
> On Thu, 02 Sep 2010 13:29:48 -0700, Karl E. Peterson <k***@exmvps.org> Oh man, shoeboxes full of punchcards? Yeah, that's the era I changed > wrote: > >> Heh, if your "drive" was only 160kb, hellyeah! <g> > > Drive? You mean cards, right? Paper cards? Fortunately I missed > the era of paper tape. my major to Geology. I might actually still have some of the paper tape stuff I did, before that, though. <g> On Tue, 07 Sep 2010 14:53:34 -0700, Karl E. Peterson <k***@exmvps.org>
wrote: >on 9/6/2010, Tony Toews supposed : I didn't know you were a Geologist? So am I.>> On Thu, 02 Sep 2010 13:29:48 -0700, Karl E. Peterson <k***@exmvps.org> >> wrote: >> >>> Heh, if your "drive" was only 160kb, hellyeah! <g> >> >> Drive? You mean cards, right? Paper cards? Fortunately I missed >> the era of paper tape. > >Oh man, shoeboxes full of punchcards? Yeah, that's the era I changed >my major to Geology. I might actually still have some of the paper >tape stuff I did, before that, though. <g> I was a bizzare trail that lead from from Brunton & Pick to Monitor & Mouse. <bg> -ralph ralph wrote :
Show quoteHide quote > On Tue, 07 Sep 2010 14:53:34 -0700, Karl E. Peterson <k***@exmvps.org> They went on field trips! <g> I actually lasted about two years in the > wrote: > >> on 9/6/2010, Tony Toews supposed : >>> On Thu, 02 Sep 2010 13:29:48 -0700, Karl E. Peterson <k***@exmvps.org> >>> wrote: >>> >>>> Heh, if your "drive" was only 160kb, hellyeah! <g> >>> >>> Drive? You mean cards, right? Paper cards? Fortunately I missed >>> the era of paper tape. >> >> Oh man, shoeboxes full of punchcards? Yeah, that's the era I changed >> my major to Geology. I might actually still have some of the paper >> tape stuff I did, before that, though. <g> > > I didn't know you were a Geologist? So am I. Geology program, then made the final major shift to Geography. I sorta lost focus at the upper-level Mineralogy phase. That got to be too much like CS, in that it was all indoor focused. > I was a bizzare trail that lead from from Brunton & Pick to Monitor & I'd enjoyed programming for years, but got into the very earliest > Mouse. <bg> phases of GIS (then called "Computer Cartography") in school. That kinda let me bring it all together. On Tue, 07 Sep 2010 16:26:30 -0700, Karl E. Peterson <k***@exmvps.org>
wrote: Show quoteHide quote >ralph wrote : I had been in the Chihuahuan Desert 4 months field mapping, when this>> On Tue, 07 Sep 2010 14:53:34 -0700, Karl E. Peterson <k***@exmvps.org> >> wrote: >> >>> on 9/6/2010, Tony Toews supposed : >>>> On Thu, 02 Sep 2010 13:29:48 -0700, Karl E. Peterson <k***@exmvps.org> >>>> wrote: >>>> >>>>> Heh, if your "drive" was only 160kb, hellyeah! <g> >>>> >>>> Drive? You mean cards, right? Paper cards? Fortunately I missed >>>> the era of paper tape. >>> >>> Oh man, shoeboxes full of punchcards? Yeah, that's the era I changed >>> my major to Geology. I might actually still have some of the paper >>> tape stuff I did, before that, though. <g> >> >> I didn't know you were a Geologist? So am I. > >They went on field trips! <g> I actually lasted about two years in the >Geology program, then made the final major shift to Geography. I sorta >lost focus at the upper-level Mineralogy phase. That got to be too >much like CS, in that it was all indoor focused. > >> I was a bizzare trail that lead from from Brunton & Pick to Monitor & >> Mouse. <bg> > >I'd enjoyed programming for years, but got into the very earliest >phases of GIS (then called "Computer Cartography") in school. That >kinda let me bring it all together. guy asked if anyone would be willing to go back to San Francisco and help transcribe our data into their newly purchased computer. My arm shot up so fast it almost left my socket. -ralph ralph wrote :
Show quoteHide quote > On Tue, 07 Sep 2010 16:26:30 -0700, Karl E. Peterson <k***@exmvps.org> LOL! I suppose I'd have jumped for those ocean breezes, too! :-)> wrote: > >> ralph wrote : >>> On Tue, 07 Sep 2010 14:53:34 -0700, Karl E. Peterson <k***@exmvps.org> >>> wrote: >>> >>>> on 9/6/2010, Tony Toews supposed : >>>>> On Thu, 02 Sep 2010 13:29:48 -0700, Karl E. Peterson <k***@exmvps.org> >>>>> wrote: >>>>> >>>>>> Heh, if your "drive" was only 160kb, hellyeah! <g> >>>>> >>>>> Drive? You mean cards, right? Paper cards? Fortunately I missed >>>>> the era of paper tape. >>>> >>>> Oh man, shoeboxes full of punchcards? Yeah, that's the era I changed >>>> my major to Geology. I might actually still have some of the paper >>>> tape stuff I did, before that, though. <g> >>> >>> I didn't know you were a Geologist? So am I. >> >> They went on field trips! <g> I actually lasted about two years in the >> Geology program, then made the final major shift to Geography. I sorta >> lost focus at the upper-level Mineralogy phase. That got to be too >> much like CS, in that it was all indoor focused. >> >>> I was a bizzare trail that lead from from Brunton & Pick to Monitor & >>> Mouse. <bg> >> >> I'd enjoyed programming for years, but got into the very earliest >> phases of GIS (then called "Computer Cartography") in school. That >> kinda let me bring it all together. > > I had been in the Chihuahuan Desert 4 months field mapping, when this > guy asked if anyone would be willing to go back to San Francisco and > help transcribe our data into their newly purchased computer. My arm > shot up so fast it almost left my socket. On 02/09/2010 19:44, Karl E. Peterson wrote:
> Mayayana has brought this to us : ....among many other things.>> If you want it to be NTFS then I assume that you're >> an NTFS lover who tries to run with limited rights >> whenever possible. > > Nope. NTFS supports files >2GB and FAT32 doesn't. That simple. Proper long file name support (rather than a hack), No feasible limit on number of files in a folder (normally only effects bad designed apps, but stuff we need to live with none the less.) etc.. -- Dee Earley (dee.ear***@icode.co.uk) i-Catcher Development Team iCode Systems (Replies direct to my email address will be ignored. Please reply to the group.) Tom Shelton wrote :
> Abhishek explained : That tip is buying more trouble than its saving! Leaving flash drives >> Can be done using 3rd party tools tool, but most people dont know about it, >> and consumers dont use cmd line tools. > > Are you sure about your claim? I'm pretty sure that I was able to format my > flash drive using ntfs on xp... And not from the commandline either. > > Yeah, thought so: > http://www.online-tech-tips.com/computer-tips/format-usb-ntfs/ "optimized for performance" can save a lot of grief. That turns off write-caching, effectively allowing you to pull the drive anytime, without doing so "safely." (I'm not recommending doing that, just saying that when you forget to do it the "safe" way you'll be that much less likely to corrupt things.) It's really far, far easier to do it "the old-fashioned way" and simply run CONVERT against it. Karl E. Peterson used his keyboard to write :
Show quoteHide quote > Tom Shelton wrote : I agree. I just was remebering being able to do it in the gui on xp :) >> Abhishek explained : >>> Can be done using 3rd party tools tool, but most people dont know about >>> it, and consumers dont use cmd line tools. >> >> Are you sure about your claim? I'm pretty sure that I was able to format >> my flash drive using ntfs on xp... And not from the commandline either. >> >> Yeah, thought so: >> http://www.online-tech-tips.com/computer-tips/format-usb-ntfs/ > > That tip is buying more trouble than its saving! Leaving flash drives > "optimized for performance" can save a lot of grief. That turns off > write-caching, effectively allowing you to pull the drive anytime, without > doing so "safely." (I'm not recommending doing that, just saying that when > you forget to do it the "safe" way you'll be that much less likely to corrupt > things.) > > It's really far, far easier to do it "the old-fashioned way" and simply run > CONVERT against it. To be honest, i didn't even read the whole article - just enough to know I had been able to do it that way :) -- Tom Shelton Tom Shelton explained :
Show quoteHide quote > Karl E. Peterson used his keyboard to write : Yep, it's possible, but probably not smart. That said, I don't have >> Tom Shelton wrote : >>> Abhishek explained : >>>> Can be done using 3rd party tools tool, but most people dont know about >>>> it, and consumers dont use cmd line tools. >>> >>> Are you sure about your claim? I'm pretty sure that I was able to format >>> my flash drive using ntfs on xp... And not from the commandline either. >>> >>> Yeah, thought so: >>> http://www.online-tech-tips.com/computer-tips/format-usb-ntfs/ >> >> That tip is buying more trouble than its saving! Leaving flash drives >> "optimized for performance" can save a lot of grief. That turns off >> write-caching, effectively allowing you to pull the drive anytime, without >> doing so "safely." (I'm not recommending doing that, just saying that when >> you forget to do it the "safe" way you'll be that much less likely to >> corrupt things.) >> >> It's really far, far easier to do it "the old-fashioned way" and simply run >> CONVERT against it. > > I agree. I just was remebering being able to do it in the gui on xp :) To > be honest, i didn't even read the whole article - just enough to know I had > been able to do it that way :) any idea if that sort of setting is persisted with the drive or the drive letter or _________? on 9/1/2010, Abhishek supposed :
> Can be done using 3rd party tools tool, but most people dont know about it, No need for 3rd party tools.> and consumers dont use cmd line tools. Hard to imagine most consumers *wanting* to convert to NTFS, much less even knowing it's an option. I agree with that. But all it takes is a quick Google to find out how extremely easy it is, if one wanted to. I think anyone who cares enough to search out the answer would find dropping to a command window pretty trivial. "Mike Williams" <M***@WhiskyAndCoke.com> wrote in message "Never" use CSIDL_LOCAL_APPDATA for settings, use CSIDL_APPDATA instead(if 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 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 One thing that could bring a source of confusion to the user is when the > 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? 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 "Nobody" <nob***@nobody.com> wrote in message Thanks for the information. In this scenario the roaming advantage of 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 . . . 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 Thanks a lot for that one. I never considered the possibility that some > the folder doesn't necessarily exits 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 "Nobody" <nob***@nobody.com> wrote in message I've just tried that, both with CSIDL_APPDATA and with CSIDL_LOCAL_APPDATA news:i5d6hg$ffu$1@speranza.aioe.org... > . . . use CSIDL_APPDATA instead along > with CSIDL_FLAG_CREATE . . . 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/library/bb762203(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 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? i think %temp% is for backward compatiblity for older apps, as it returns
short path name. it points to local appdata temp Show quoteHide quote "Mayayana" <mayayana@invalid.nospam> wrote in message news:i5gah7$bq6$1@news.eternal-september.org... | 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? | | | |
|||||||||||||||||||||||
Other interesting topics