|
Sherzaad13291325 wrote: the code works if I chose a different location, it seems to me that there may be some restriction or filepath length issue
My suspicion was right! turns out is WAS a filepath length. Converted the 'fullpath' to its 'shortpath' and code is now running as it did before 
modified 3-Feb-24 7:43am.
|
|
|
|
|
Based on the code you posted, no, it wasn't filepath length. The max length of a filepath is 260 characters. The max length of the Windows command line is 32K, and I seriously doubt your command line was that long.
|
|
|
|
|
You are right that the OP has not provided enough info for us to certainly conclude that it was a path length problem. But we certainly cannot reject it.
Then file name of his script, "enableTouchScreen.ps1", is 21 chars. He reports that when it is moved to "the 'currentDirectory' (ie the Project debug folder)", it won't work. If the length of 'cd' exceeds 238 chars, the full script file name would exceed 260 chars.
I certainly have seen project directory paths exceeding 238 chars; in my last job, the naming rules made it more or less the standard. What surprises me more is that the OP does not run into this problem with other files in his project as well. Maybe it is set up will all relative naming (and no tools expand it to an absolute path), or all files are located in other directories with shorter paths, or all the other tools are prepared for long file paths.
260 chars was the old DOS/FAT limit. As long as you use new Windows file system APIs that can handle longer NTFS paths, they can be up to approx. 32 Ki characters. The 260 length is not really in NTFS or Windows, but in individual programs using old APIs. These APIs have not been extended to long file names because lots of old program have allocated 261 chars for a file path buffer, frequently with no overrun check as that is the maximum length. If an old API used to return names limited by MAX_PATH after a minor update starts returning names of several hundred or thousand characters, then you would have a buffer overrun.
It is a pity that the myth of Windows being limited to 260 chars are still living. It makes lots of programmers continue making 261 char allocations, and the old APIs that should have been marked as deprecated 20 years ago and removed 10 years ago. Backwards compatibility is great (and Windows is far better at it than competing OSes!) but sometimes it goes too far.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
trønderen wrote: 260 chars was the old DOS/FAT limit. As long as you use new Windows file system APIs that can handle longer NTFS paths, they can be up to approx. 32 Ki characters. The 260 length is not really in NTFS or Windows, but in individual programs using old APIs.
And that's why I always say the limit is 260 characters. Yes, if using the new stuff, it's 32K, but developers, all too commonly, don't use the newer API's because the code they wrote at least a decade ago never gets updated. I've seen it way too often, even today.
|
|
|
|
|
But by keeping that old myth alive (stating unconditionally that "The max length of a filepath is 260 characters", with no reservation, like an absolute truth), you contribute to the problem. Lots of programmers believe that as long as they allocate a 261 char buffer for the file name, they are safe and can handle all the paths there are.
But they cannot. Windows software can create longer paths, as the OP experienced.
I would much prefer to make a reference to the long filenames, and add a warning: Beware that if the path exceeds 260 char, then software using old FAT oriented calls to obtain the file path might fail.
Trying to keep the solution to the problem secret, because some programmers is not aware of it, is no good way to bring the world forward. In my eyes, that is.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
No, I don't. Developers who refuse to update their code contribute to the problem, and yes, I still see those problems today. I mention the limit for compatibility reasons.
|
|
|
|
|
The problem is not due to Dave's comments, but rather the developers' failure (or is that refusal) to make use of official documentation. We see plenty of questions where the OP says they cannot find something via Google. And yet when we repeat the search it takes us straight to the MSDN page in question.
|
|
|
|
|
Richard MacCutchan wrote: The problem is not due to Dave's comments, but rather the developers' failure (or is that refusal) to make use of official documentation.
Or, the problem is that when some experienced programmer states "The limit IS 260 characters!" (and that is just a fact), the inexperienced programmer sees no need to go to the official documentation to learn that the experienced programmer had given him incorrect information 'just to be on the safe side'.
I willingly admit that when a mate tells me how to do something, or how I can not do it (e.g. using longer paths), I frequently take that as a valid piece of information. I do not always verify against the official documentation every piece of information or every advise I receive. Maybe I should, but that would take a lot of time. I allow myself to learn from others.
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
Dave Kreskowiak wrote: The max length of a filepath is 260 characters. The max length of the Windows command line is 32K
I didn't find an authoritative source but googling I did find recent posts that suggests that the length limit for Powershell scripts is 260 characters.
Presumably the command execution would fail then. Probably with a return value of '2'? (File not found?).
|
|
|
|
|
float n = 0.2f;
Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );
n = 0.5f;
Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );
n = 0.6f;
Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );
n = 1.5f;
Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );
n = 1.2f;
Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );
n = 1.7f;
Console.WriteLine( $"{n:F2}: {Math.Round( n, 0 ):F2}" );
Answer:
0.20: 0.00
0.50: 0.00
0.60: 1.00
1.50: 2.00
1.20: 1.00
1.70: 2.00
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Take a look at IEEE 754 rounding. Wikipedia (IEEE 754 Rounding rules[^]) is a good starting point, but not necessarily the ultimate answer.
For any calculation with bits beyond what can be represented in the result definition, as long as they are available they should determine rounding. However, if the true result of a calculation is exactly one half of the resolution (so you do not have any hidden bits to help you), experts on error propagation will tell you that rounding up or down at random, or e.g. every second time, will reduce the average error (when we are talking about zillions of calculations and result roundings).
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
As always, it depends. The Round function can use different rules depending on what you pass it. It's all covered in the documentation on Round[^]. Just make sure you have the correct framework you're using selected in the top left of the page.
|
|
|
|
|
It does both, does it not?
0.5 => 0
1.5 => 2
2.5 => 2
3.5 => 4
etc.
This was mainly Carl Friedrich Gauss's idea. Basically, its a choice you make, and you could choose differently. Your computer might do it differently...
|
|
|
|
|
The question is not how to round.
The question is what exact business rules are being addressed.
This is much more true when dealing with currency of any sort. Often (always?) with currency rounding is covered by laws, regulations and/or contracts. And in complex systems one must do a data dip to determine the exact rule that applies for that case (always with a timestamp.)
|
|
|
|
|
I did not ask "how" ... I learned to add 0.5 or 0.05 or .005 in elementary school. "Should" implies Generally Accepted Accounting Practices (GAAP) ... or what every search generally says about "rounding".
I don't expect that every person who learned these "rules" goes back to check every day to see if "convention" has changed.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
Not sure what your original post was referring to.
But my point is that business rules, not code usage, determines how rounding should happen. So no one should ever code rounding without understanding the business rules that require it.
|
|
|
|
|
I think you just want to add your 2 cents regardless of whether you understand the "original post" or not.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
|
My "question" was more philosophical than technical.
I have built ERP systems from the ground up that passed audit from national accounting firms. My "naive" approach to rounding was never a problem. (And this was "before" .NET)
The concept of randomly deciding to go up or down, is not "determinate" from an auditing point of view.
"Before entering on an understanding, I have meditated for a long time, and have foreseen what might happen. It is not genius which reveals to me suddenly, secretly, what I have to say or to do in a circumstance unexpected by other people; it is reflection, it is meditation." - Napoleon I
|
|
|
|
|
There is a good option there which is not random: always round to the even number. Not being an accountant I don't know if auditors have their own rule.
|
|
|
|
|
I have worked at different fintech companies for 10 years.
At least in one part of the industry rounding was specifically regulated. It varied by locality. And over time.
|
|
|
|
|
Yes but that is accounting, not C#/.NET.
|
|
|
|
|
So what about a programming developing an accounting application in C#?
Religious freedom is the freedom to say that two plus two make five.
|
|
|
|
|
What would you do in any other language?
There isn't a magic-bullet solution to this problem in any language. If the rules are subject to change, then you either need to recompile, or have some means of configuring the code to use specific rounding rules in specific situations.
The only complaint with .NET / C# is if you're stuck with .NET Framework, where you only options are "to even" or "away from zero"; the options for "to zero", "to negative infinity", and "to positive infinity" were added in .NET Core 3.0.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Richard Deeming wrote: is if you're stuck with .NET Framework,
You can of course add code to potentially handle other situations.
Probably the most stringent part of this is that the developer should be able to show why they are using a specific rounding and then document it. Probably need to explain it as well. Both for potential audits as well as insuring future maintenance programmers do not 'fix' anything.
I have certainly had to explain this to non-developers before that should have already understood it since they were dealing with financial decisions daily.
This would always be the case when dealing with financial transactions. This can even become a problem when developers decide to store currency amounts in floating point data types. Then even something like addition can be impacted by rounding.
I never experienced a problem with scientific results but when I was programming for that I was not aware of any of the issues. To be fair back then even financial institutions did not seem aware of it. The theory was known but in had not made a transition to practical usage (in many cases.)
Richard Deeming wrote: If the rules are subject to change, then you either need to recompile,
It probably is going to be more complicated than that. For one time calculations then ok. But one must insure that that business rule will never change.
The case I encountered was where the company was using paper records printed years before. Sometimes those were lost. So they printed (ran a report) again. After the rules had changed. No one in the company was aware of this problem until I pointed it out once I needed to do an update on the report.
As you pointed out this required a dynamic solution which I implemented.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
