LG webOS SDK
-
That's what we're discussing
Because on a machine where the Username folder is read-only, DropBox will fail to install.
Emphasis mine
-
Getting confused s between the original WTF and the current argument.
The same argument should apply though, if C:\Users\Jaloopa is read only but I have write access to all the subfolders then nothing should be affected in terms of basic login. Dunno what you managed to screw up in your VM though
-
Well, this is what happens if I try to do that in a VM...
<img src=http://www.vistax64.com/attachments/tutorials/22222d1295951224-user-profile-error-logged-temporary-profile-windows7-jpg">
Doesn't look to me like a successful login
What do you actually want to happen? Start with a pre-configured read-only profile which is cleaned every time you logon? Because that's what Mandatory profiles are for.
-
To be fair, Microsoft has changed its recommendations and best practices of where you should put what so many times, it's hard to blame the devs for failing to keep track.
The folder names have changed, but the guidance that goes with them has not, and those folder names were an implementation detail anyway.@sloosecannon said:Where is this documented?
- SHGetSpecialFolderPath (from Windows 95 through Windows 10, desktop apps),- SHGetFolderPath (from Windows NT 4 through Windows 10, desktop apps),
- SHGetKnownFolderPath (from Windows Vista through Windows 10, desktop and enterprise immersive apps),
- [HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders] (Windows 95 M3 beta only, do not use)
- CSIDL environment variables (from Windows 98 through Windows, 10 desktop apps),
- Windows Installer autoprops (from Windows 98 through Windows 10, desktop apps),
- My.Computer.FileSystem.SpecialDirectories (from Windows 98 through Windows 10, desktop and enterprise immersive apps),
- Environment.GetFolderPath (from Windows 98 through Windows 10, desktop and enterprise immersive apps),
- Windows.Forms.Application (from Windows 98 through Windows 10, desktop and enterprise immersive apps),
- Windows.Storage.ApplicationData (from Windows 8 through Windows 10, all applications)@blakeyrat said:
Microsoft generally seems to assume everybody already knows this.
... damn,
@blakeyrat said:It made more sense before Microsoft made Photos and Videos. Which, IMO, belong inside Documents, and not outside it.
They used to be inside it, but got moved outside in Vista.@abarker said:I believe that @cartman82 was referencing roaming profiles, which are a very real thing.
Blakey knows; he has that at work, which causes no end of lulz when Eclipse and other apps completely fail to understand that, or quotas, or folder redirection, and shit a mess everywhere shortly before dying.@sloosecannon said:Please explain how to log in with a read-only user folder.
EnsureNTUSER.DATand its associated log files are read-write, or that Group Policy loads them from an alternate location.
-
Doesn't look to me like a successful login
You did something other than what you said you did. Probably what Jaloopa mentioned, you set read-only on the AppData/Roaming folder.
Remember, in NT, child folders don't (necessarily) inherit permissions from their parent folders.
-
Blakey knows; he has that at work, which causes no end of lulz when Eclipse and other apps completely fail to understand that, or quotas, or folder redirection, and shit a mess everywhere shortly before dying.
Not anymore, that was like 3 jobs ago.
But working at a place where
/Users/Blakeyratwas read-only and that actually actively used Roaming Profiles was sure a great way to identify buggy-ass software from idiot developers who didn't know how Windows worked.
-
OK, fine, I concede that, with trickery, you can make the Users folder RO.
But why in the hell would you want to?
Please give me a good reason for wanting to do that.You did something other than what you said you did. Probably what Jaloopa mentioned, you set read-only on the AppData/Roaming folder.
Remember, in NT, child folders don't (necessarily) inherit permissions from their parent folders.
Default Windows setup, used a different account, set RO on folder, failed to log in.
-
Incidentally, you'll also fail to log in properly because you can't write to critical files. So that's an issue...
I don't even understand the question.
You just ... do it? And it works?
Like do you want detailed instructions on how to type your password or something?
I wonder how many things would break when the Registry API finds out it can't write anything to NTUSER.DAT (which is where HKCU lives on disk)...
The same argument should apply though, if C:\Users\Jaloopa is read only but I have write access to all the subfolders then nothing should be affected in terms of basic login. Dunno what you managed to screw up in your VM though
C:\Users\Jaloopa\NTUSER.DAT-- that's what'll break, and I suspect it'll break horribly if not for Windows realizing it will and doing something sane, like creating a temporary profile.Ensure
NTUSER.DATand its associated log files are read-write, or that Group Policy loads them from an alternate location.
Yup -- I don't know why Blakey somehow can't reckon that not being able to write toHKEY_CURRENT_USERmight just break something?Roaming Profiles, of course, are a different ball of wax, as HKCU is then stored in a different place...
-
Unless of course you manually set permissions for
NTUSER.DATback to RW... Which....
?
-
More like "the registry was invented in Windows 95, and never met filesystem ACLs until at least NT 4 or later"
-
No, convention says it should put it under
/home/myuser/.lgsdkTvregisterybecause it's a user land application, not system wide... unless it asked for it.
-
Well, technically,
~/.lgsdkTvregistery; there's a reason the alias exists ;)
-
Ah, right...I was thinking an install for system wide access.
-
OK, fine, I concede that, with trickery, you can make the Users folder RO.
What trickery? That's the way NT permissions work!
But why in the hell would you want to?
Because it's not on the local filesystem, it's on a fileserver that the Windows user has read-only access to. The fileserver had read-only for all the Windows users because it was the "old" fileserver that was longer being used to store documents (the Documents folder was redirected to another server that was read/write) but for some reason (probably laziness) they didn't also redirect the Username folder to the new file server.
I concede that's a uncommon thing to do, but it's also 100% valid in Windows. And software written to the OS contract, instead of the "works on my machine!" contract, worked fine.
Default Windows setup, used a different account, set RO on folder, failed to log in.
I don't believe you. But ok, whatever.
None of this changes my point: if an application writes files in that folder, it's a bug. EVEN IF Windows fails to log on in that case, that doesn't make it not-a-bug.
I wonder how many things would break when the Registry API finds out it can't write anything to NTUSER.DAT (which is where HKCU lives on disk)...
I believe when Roaming's enabled, that's in AppData, but I could be wrong. Honestly, I'm not sure. But it works; I used a computer set up that way for months, and it worked fine.
Roaming Profiles, of course, are a different ball of wax, as HKCU is then stored in a different place...
Yeah, see?
You're busy calling me an idiot, then in the last sentence you're like, "oh wait I guess he was right all along."
-
Yeah.
/homeis just plain wrong though...
-
Because it's not on the local filesystem, it's on a fileserver that the Windows user has read-only access to. The fileserver had read-only for all the Windows users because it was the "old" fileserver that was longer being used to store documents (the Documents folder was redirected to another server that was read/write) but for some reason (probably laziness) they didn't also redirect the Username folder to the new file server.
I admit that's a weird thing to do, but it's also 100% valid in Windows.
Filed Under: My computer doesn't work when I put it in an industrial heater while submerging it it acid
-
Do you have a specific comment to make, or are you just wasting space and time?
-
Another thing which made me
This thing has a vmdk image of several MB and for some reason it's duplicated in
/home/.lgsdkTvregisteryand the installation folder I choose.It also contains a JRE folder... twice... one for the emulator and another for the IDE which is a custom Eclipse that won't work and I don't want to waste more time with this today.
-
That's a ridiculous setup and you (should) know it. No wonder things didn't work properly
Just like it's not Microsoft's responsibility if people do stupid things with their OS, it's not the application's fault if a program doesn't work on some whackball setup that no sane sysadmin would create
-
This thing has a vmdk image of several MB and for some reason it's duplicated in /home/.lgsdkTvregistery and the installation folder I choose.
Resetting the emulator is accomplished by copying the VMDK from the installation folder to the SDK's "user account's" folder, overwriting the existing copy.
Filed under: wild ass-guess
-
Because Virtual Box doesn't have snapshots... yes it does!
-
That's a ridiculous setup and you (should) know it.
Doesn't matter; it's well within the terms of the OS contract.
There's no contract that says
/Users/Blakeyratis on a local drive. There's no contract that says/Users/Blakeyratis on the same drive (or in the same folder tree) as/Users/Blakeyrat/Documents.That configuration was well-within the OS contract.
If you're not building software to the OS contract, you're building broken buggy shit. You are bad at your job, and you should be doing something else, like shoveling shit out of stables.
REGARDLESS of what you think of that one particular company's setup.
See this is the danger of the Linux community. Because they're working off an OS where the OS contract is basically non-existent, where the rules are "eh, just do what seems to kind of work some of the time I guess?" well they end up with a shitty, buggy, crappy OS. But at the same time, they think that development process is normal. And then when they go to Windows or OS X, they code the same way. "Well it kind of sort of maybe works a bit on my machine, SHIP IT!"
Meanwhile, real software developers, who understand that OSes have contracts are being overrun by this shitty Linux "developers" producing broken shit. And suddenly, people are sitting here in forums posting things like, "well your configuration was slightly unusual, therefore you should have expected things to break." WHAT THE FUCK!
No. Wrong. That attitude is so wrong I don't even know where to start.
-
Well, I still have yet to see anything official from MS that tells me not to put my application's folders in
%USERPROFILE%/your_language's_system_call_to_get_USERPROFILE, so..... yeah. I'd assume I'm within the contract as well, and maybe it conflicts with itself?
-
See this is the danger of the Linux community. Because they're working off an OS where the OS contract is basically non-existent, where the rules are "eh, just do what seems to kind of work some of the time I guess?" well they end up with a shitty, buggy, crappy OS. But at the same time, they think that development process is normal. And then when they go to Windows or OS X, they code the same way. "Well it kind of sort of maybe works a bit on my machine, SHIP IT!"
Meanwhile, real software developers, who understand that OSes have contracts are being overrun by this shitty Linux "developers" producing broken shit. And suddenly, people are sitting here in forums posting things like, "well your configuration was slightly unusual, therefore you should have expected things to break." WHAT THE FUCK!
No. Wrong. That attitude is so wrong I don't even know where to start.
Hahahahahahahaha.
How is this relevant?
It's also not correct, but I think that's kinda par for the course. POSIX compliance is a thing.
-
Well, I still have yet to see anything official from MS that tells me not to put my application's folders in %USERPROFILE%/your_language's_system_call_to_get_USERPROFILE,
Right; you probably also haven't seen anything from them that says to not make your app a gigantic rectangle of flashing eye-searing red and yellow. So you better do that also, just to be safe.
Look, like I've said a half-dozen times, you can do whatever the fuck you want on your own machine. Just be aware that what you've done is a bug, and when you move that software to another computer it's likely it'll break. If you even aware it's a bug, that (sadly) puts you in probably the top 25% of Windows programmers.
POSIX compliance is a thing.
Not really.
How many Linux programs break when there's a space in a filename? And yet POSIX allows that.
POSIX is a standard, but Linux developers don't code to it.
-
Right; you probably also haven't seen anything from them that says to not make your app a gigantic rectangle of flashing eye-searing red and yellow. So you better do that also, just to be safe.
Actually, yes I have. Microsoft does a pretty good job with their UI standardization docs.
Look, like I've said a half-dozen times, you can do whatever the fuck you want on your own machine. Just be aware that what you've done is a bug, and when you move that software to another computer it's likely it'll break. If you even aware it's a bug, that (sadly) puts you in probably the top 25% of Windows programmers.
What says it's a bug? How do we know it's a bug?Why isn't making the user folder RO a bug? I think it's a bug.
Guys, making the user folder is a bug, because I say so BUGGZZZZZZ
-
CSIDL_PROFILE: The user's profile folder. A typical path is C:\Documents and Settings\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA.
That's in the list of CSIDLs to pass to the native folder-fetching functions, the list of environment variables, and the list of Environment.SpecialFolders.
-
> CSIDL_PROFILE: The user's profile folder. A typical path is C:\Documents and Settings\username. Applications should not create files or folders at this level; they should put their data under the locations referred to by CSIDL_APPDATA or CSIDL_LOCAL_APPDATA.
That's in the list of CSIDLs to pass to the native folder-fetching functions, the list of environment variables, and the list of Environment.SpecialFolders.
AAAaaaand that's what I was looking for.
Thank you @TwelveBaud@Blakeyrat, now you can say it's a bad idea. Because there's something official that backs it up.
That's how that kind of stuff works.
-
What says it's a bug? How do we know it's a bug?
I've already answered these questions.
Why isn't making the user folder RO a bug? I think it's a bug.
What you think doesn't matter. It's allowed by the OS contract, therefore it is not a bug.
Guys, making the user folder is a bug, because I say so BUGGZZZZZZ
Look, if you don't give a shit about writing quality software, fine. There's no point making fun of me, just do what you want.
I'm still going to talk about it, though, because the more I get the message out, the less shitty software there will be. Most developers (I hope) aren't like you. Most developers don't like putting bugs in their programs.
@Blakeyrat, now you can say it's a bad idea.
I don't give a shit about getting your permission.
-
I've already answered these questions.
No you didn't.
@TwelveBaud answered those questions.For the record, TIL. So, if I ever write a program that might do that in the future, I'll do exactly what the documentation he referenced said. Not because some guy on the internet told me to, but because that guy on the internet also gave me the standard that said what to do.
-
A.k.a. Blakeyrat wins... again.
-
No, Blakeyrat chose the winning side. Blakeyrat was spewing gibberish until someone came in and made his point for him.
-
@TwelveBaud answered those questions.
He probably bookmarked my post, which made it easy.
-
Now I have too :)
-
Also,
POSIX is a standard, but Linux developers don't code to it.
But working at a place where /Users/Blakeyrat was read-only and that actually actively used Roaming Profiles was sure a great way to identify buggy-ass software from idiot developers who didn't know how Windows worked.
Surely I'm not the only one seeing the irony here?
-
Surely I'm not the only one seeing the irony here?
What irony?
Linux developers don't code to POSIX.
Windows developers don't code to their OS contract either. Linux developers "porting" to Windows especially don't.
Where's the irony?
-
-
@sloosecannon said:
Surely I'm not the only one seeing the irony here?
What irony?
Linux developers don't code to POSIX.
Windows developers don't code to their OS contract either. Linux developers "porting" to Windows especially don't.
Where's the irony?
The fact that you love to bash OSS developers for "not following their standards" when developers for your beloved Windows OS don't follow it either.
Maybe the issue isn't the "OSS" part of that phrase, but the "developer" part.
-
-
Lol saw that, wasn't gonna comment.
-
Y'all should bookmark this post.
No, use https://technet.microsoft.com/en-us/library/dd560744(v=ws.10).aspx instead. It's a newer version and mentions the Vista-and-later names of those directories. For example,
CSIDL_APPDATAThe file-system directory that serves as a common repository for application-specific data. A typical path is C:\Documents and Settings\username\Application Data or C:\Users\username\AppData\Roaming.
-
The fact that you love to bash OSS developers for "not following their standards" when developers for your beloved Windows OS don't follow it either.
I also bash Windows developers for that. For example, the DropBox developers I bashed in this very thread.
So... where's the irony?
Or are you just illiterate and missed that I've already done the thing you're saying I never do?
-
dude. not cool.
To be fair, it's not as if @blakeyrat's not telling the truth. He's been talking about this all the way back to 2007 or whenever the great Aptana topic happened.
-
...
Never mind.
Annnywaayysss...
Yeah, writing to
/home/is quite the WTF. Did someone accidentally a variable somewhere and intend to write to/home/username?
-
Oops.
-
Why? You put any number of things in Dropbox, not just documents.
Because "Documents" in Windows means "where the user's files go". Appdata is "where program data files, like browser cache or game saves" go.
Since you store your files (theoretically) in Documents, Dropbox should also use that.
At least, that's the official position of MS.
-
Yeah... Unfortunately that gets annoying when you have something that meets both or neither of those categories. I think that's the main reason people put stuff in the
Users\namefolder
-
(Keep in mind, Microsoft considers an Access database a "document". Similarly, a Visual Studio solution is a "document". I don't know if that helps?)
Someone probably got caught up too much in desktop metaphors. Generic "files" would have probably been a better word. Especially since, as you sort of imply, "Photos" and "Videos" blur the distinction.
-
...
Never mind.
Annnywaayysss...
A.k.a. Blakeyrat wins... again. Twice in one thread.
You guys gotta stop going up against Blakeyrat if you can't cut it.
-
Heh.
I'm almost tempted to flag for whoosh, but I have work to do.
Someone giving up because you're too obtuse does not mean you win. It means you lose. By default.
