Because he is an idiot
-
Our application stores configuration and connection settings in the common app data folder (Environment.SpecialFolder.CommonApplicationData).
This is application specific data that applies to all users, so it's the right place and (apart from installation) the program never writes to this path.We got a complaint from a new installation at a site where the application failed to read data from this path. Turns out read access was denied for all users. We responded, explaining why we use this path, included the link to the MSDN article and recommend they they enable read access.
We received a quick response from their top IT guy saying only the following: "This is not possible."
Wondering if there's some kind of visualized environment or software conflict we weren't aware of, I spoke with our ops guy on site.
"Why does [redacted] say this is not possible?"
"Because he is an idiot."Turns out he had no real reason to lock down access to a path intended to be used in this way but that didn't stop the uphill battle that followed.
-
@MoSlo said:
We got a complaint from a new installation at a site where the application failed to read data from this path. Turns out read access was denied for all users.
Which is why our installers have a "custom installation" option that enables to overwrite the folders that the application accesses. That's probably an easier solution than to argue with idiots
-
@MoSlo said:
Wondering if there's some kind of visualized environment or software conflict we weren't aware of, I spoke with our ops guy on site. "Why does [redacted] say this is not possible?" "Because he is an idiot."
TRWTF is you not recognizing this as a quote (okay, a minor paraphrase) of a line from "Heathers".
-
TRWTF is recognizing a line from "Heathers".
-
TRWTF is you for assuming he's seen Heathers. That movie came out 25 years ago.
-
TRWTF is you for assuming I made that assumption. There's a reason I used the phrase "recognizing a line from" instead of "having seen".
-
@rudraigh said:
TRWTF is you for assuming he's seen Heathers. That movie came out 25 years ago.
TRWTF is you thinking that a person knows nothing about a movie if they haven't seen it.However, recognizing a line from Heathers is still a WTF.
-
What sort of data needs to be written during installation, and used by all users, but never changed? (let me guess... license key) If it's part of the install, why not put in in the app's folder in Program Files? (let me guess... license key)
-
@MoSlo said:
Our application stores configuration and connection settings in the common app data folder (Environment.SpecialFolder.CommonApplicationData). This is application specific data that applies to all users, so it's the right place and (apart from installation) the program never writes to this path.
Thank you. Dare I assume that you're using CommonApplicationData because you've also written your installer to default to something outside of Program Files?
The number of times I hear about 32 bit apps that require users to have write access to C:\Program Files on 64 bit systems, regardless of language, and require UAC to be turned off to install... just, thank you.
-
Which is why our installers have a "custom installation" option
Agreed. This was the first complaint over this path (in the 5 years of the product's life) and that's what we changed to permanently solve this.What sort of data needs to be written during installation, and used by all users, but never changed? If it's part of the install, why not put in in the app's folder in Program Files?"
I admit I oversimplified. There are other user roles where the data are changed, but not for the basic user role for which most users work with the software. Another reason to customize this path.Dare I assume that you're using CommonApplicationData because you've also written your installer to default to something outside of Program Files?"
Erm, no. That's a terrible assumption. We're using CommonApplicationData for the reasons it's intended; I've also fought with products that need like write access are you describe but we're not one of those.
-
@MoSlo said:
Which is why our installers have a "custom installation" option
Agreed. This was the first complaint over this path (in the 5 years of the product's life) and that's what we changed to permanently solve this.What sort of data needs to be written during installation, and used by all users, but never changed? If it's part of the install, why not put in in the app's folder in Program Files?"
I admit I oversimplified. There are other user roles where the data are changed, but not for the basic user role for which most users work with the software. Another reason to customize this path.Dare I assume that you're using CommonApplicationData because you've also written your installer to default to something outside of Program Files?"
Erm, no. That's a terrible assumption. We're using CommonApplicationData for the reasons it's intended; I've also fought with products that need like write access are you describe but we're not one of those.
The proper usage is "where the data is changed". "Data" is an uncountable noun in English and if you insist on hanging on using Latin grammar around it, just because you people happened to nick that word from there, I must also insist that you properly use all forms of datum (see here for a list) and also call it "il data", instead of "the data". Furthermore, when applying adjectives to "data", they MUST go after it, so instead of "well-formed data" you need to write "data formed well". In fact, for best grammar, I recommend that every sentence which contains the word "data" be written entirely in Latin.
Or you can just drop this ridiculous fetish and use it as an uncountable noun like the rest of us.
-
-
To be honest, I'm more concerned about "products that need like write access are you describe".
Da Horror!
-
@PedanticCurmudgeon said:
TRWTF is you for assuming I made that assumption. There's a reason I used the phrase "recognizing a line from" instead of "having seen".
TRWTF is me for not quoting da Doctah.
-
@MoSlo said:
Erm, no. That's a terrible assumption. We're using CommonApplicationData for the reasons it's intended; I've also fought with products that need like write access are you describe but we're not one of those.
Ah- I was confused when you said it never changed, but I see your over simplification explanation.
-
@MoSlo said:
We received a quick response from their top IT guy saying only the following: "This is not possible."
Turns out he had no real reason to lock down access to a path intended to be used in this way but that didn't stop the uphill battle that followed.
TRWTF is that the IT guy should have said, "This is not feasible." Then it would have been far easier for him to squash your petty insistence on using that area.
-
Meh, I don't believe our insistence was being petty. We have a real need for a space to share data between multiple users. Sure we needed to customize it (and we did) but we have to integrate with an old tech that isn't so easily changed. I was being overly dramatic; putting out a new build was surely possible but it was difficult in the time frame they wanted it.
Besides, I never thought of the guy as an idiot. I'd rather work with a person that's committed to keeping their IT landscape stable than a free-for-all environment.
Through all the environments we've deployed to (loosely-maintained workstations to strict policy, visualization and citrix), I was expecting a technical reason or limitation we've never encountered before. That's why I found my colleagues reply so hilarious.
So sit back, relax and know that its all taken care of :D
-
@MoSlo said:
We have a real need for a space to share data between multiple users.
Just add a step to the installer that grants read permissions to Users to the appropriate path. Then, every time the IT guy "fixes" the permissions, doing a repair install fixes it again. If your really lucky, he'll be the one responsible to do the repair installs for people, so the only person he is causing pain for is himself.
-
@PJH said:
@Mo6eB said:
"Data" is an uncountable noun in English
Mummy! Someone on the internet is wrong again!Yes, thank you for the link proving my post.
-
@Mo6eB said:
It actually does the opposite.@PJH said:
@Mo6eB said:
Yes, thank you for the link proving my post."Data" is an uncountable noun in English
Mummy! Someone on the internet is wrong again!In Latin, data is the plural of datum and, historically and in specialized scientific fields, it is also treated as a plural in English, taking a plural verb, as in the data were collected and classified.
HTH. HAND.
-
@MoSlo said:
Meh, I don't believe our insistence was being petty. We have a real need for a space to share data between multiple users. Sure we needed to customize it (and we did) but we have to integrate with an old tech that isn't so easily changed. I was being overly dramatic; putting out a new build was surely possible but it was difficult in the time frame they wanted it.
Besides, I never thought of the guy as an idiot. I'd rather work with a person that's committed to keeping their IT landscape stable than a free-for-all environment.
Through all the environments we've deployed to (loosely-maintained workstations to strict policy, visualization and citrix), I was expecting a technical reason or limitation we've never encountered before. That's why I found my colleagues reply so hilarious.
So sit back, relax and know that its all taken care of :D
Ah, your problem is that, like many IT professionals, you forgot that technical reasons or limitations are not always the only things that mandate a company policy. It's entirely likely that some PHB told the guy to lock down security real tight and his "it's not possible" simply meant "it's not possible to change the Chief Security Officer's mind, and I don't want to get fired trying"
-
@PJH said:
@Mo6eB said:
"Data" is an uncountable noun in English
Mummy! Someone on the internet is wrong again!The way you quoted him makes you look like an idiot though.
Mo6eB: X is A
PJH: lol wrong [link explaining X is A and B]
-
@MoSlo said:
Meh, I don't believe our insistence was being petty. We have a real need for a space to share data between multiple users. Sure we needed to customize it (and we did) but we have to integrate with an old tech that isn't so easily changed. I was being overly dramatic; putting out a new build was surely possible but it was difficult in the time frame they wanted it.
Besides, I never thought of the guy as an idiot. I'd rather work with a person that's committed to keeping their IT landscape stable than a free-for-all environment.
Through all the environments we've deployed to (loosely-maintained workstations to strict policy, visualization and citrix), I was expecting a technical reason or limitation we've never encountered before. That's why I found my colleagues reply so hilarious.
So sit back, relax and know that its all taken care of :D
A "stable" IT landscape == a depressing working environment with a lot of PHBs.
-
@Xing Yang said:
A "stable" IT landscape == a depressing working environment with a lot of PHBs.
That's to be expected. With a stable, you expect to find a number of horses' asses.
