I have written a program using MS VS VC++ 2005 Express, /cli pure. Upon
compiling it it works fine in the GUI development environment. It also works
fine as a Debug stand-alone. ut I had an odd behavior when it comes to the
Release varsion when I renamed its project directory name it was in!
I tracked the problem down to it being the NAME of the DIRECTORY the
application is in! Let me explain. I compiled the code, and it worked in ALL
versions, including Release stand-alone. Then I moved the entire project
directory to a new location and kept the same name. It still works. Then I
changed the name of the project directory by tacking on 'XXX'. It STILL
works. But when I change the name by tacking on the currect date, it STOPPED
working!
In more detail:
Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release DIES!!
The fact it works with two different directory names proves my code access
all files *relative* to current directory (i.e., the code is directory
independent). Thus, directory name should be irrelevant. But, as indicated,
if I tack on the DATE after the project directory name, it dies.
I'm thinking it has something to do with the symbols or spaces I use in the
project directory name, or its length. Haven't experimented to tell one way
or another. I doubt it has to do with it being precisely the date
(10-25-2007) itself, but like I said, that I have spaces and '-' symbols in
it. Of course it *should* work as long as the OS allows the directory name
to be valid in the first place. I can't believe the OS intentionally would
allow a directory name to exist for which the name of the directory alone
prevents proper execution of the applications it contains.
This HAS to be a bug in the OS (operating system)!!!
[==P==]
28  2102 
>In more detail:
>
Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release DIES!!
I'm thinking it has something to do with the symbols or spaces I use in the
project directory name, or its length. Haven't experimented to tell one way
or another.
I suggest you do those tests.
>This HAS to be a bug in the OS (operating system)!!!
I doubt it - do more tests - debug it in a folder name that gives rise
to the problem.
Dave
I suggest you do those tests
OK, I did the tests. And this is what I found:
If the Directory name is 25 characters or less long it works. It it is 26
characters or more, it doesn't. And so far it doesn't matter what the
Directory is called, only how long its name is determines whether the
Release version of the program (2 directory-levels lower inside it) will die
or not.
Note that the DEBUG version works no matter what the Project Directory is
called, and Release only works if the Project Directory name is 25
characters or less in length. Actually, it is probably more tied into the
LENGTH of the FULL PATH name to the application, which is used INTERNALLY by
the stuff supporting my code (i.e., the OS or .NET Framework).
Does that sound like INTENDED BEHAVIOR to you? Sorry, but I'm pretty sure
this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :)
[==Peter==]
PS - I can assure you this has nothing to do with my code. The only time my
code accesses files is in the very beginning, where it simply loads in image
files into bitmaps (Bitmap^ bm = gcnew Bitmap( "filename") ;) and does ZERO
directory manipulation. All my files are assumed to be in the same directory
as the application's 'exe' file. And nothing is full path, or else I
couldn't change the directory path at all for it to work. And since it
always works in Debug version under the SAME Project Directory name even if
it fails under Release, well,....
PS - My program does nothing fancy, and accesses all files via relative to
the application
"David Lowndes" <Da****@example .invalidwrote in message
news:1h******** *************** *********@4ax.c om...
In more detail:
Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release DIES!!
I'm thinking it has something to do with the symbols or spaces I use in
the
project directory name, or its length. Haven't experimented to tell one
way
or another.
I suggest you do those tests.
>>This HAS to be a bug in the OS (operating system)!!!
I doubt it - do more tests - debug it in a folder name that gives rise
to the problem.
Dave
>Does that sound like INTENDED BEHAVIOR to you?
It sounds like a bug in your code (or some library code that you use).
>Sorry, but I'm pretty sure
this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :)
I wouldn't be so sure if I were you from the evidence you've got so
far!
>PS - I can assure you this has nothing to do with my code.
Run it under the debugger and find out where the problem is arising.
>And since it
always works in Debug version under the SAME Project Directory name even if
it fails under Release, well,....
The running environment for a debug build can be subtly different from
the release build.
You really need to debug the release version in the situation where
it's having a problem to find out the cause of the problem.
Dave
"Peter Oliphant" <po*******@roun dtripllc.comwro te in message
news:%2******** *******@TK2MSFT NGP05.phx.gbl.. .
>I suggest you do those tests
OK, I did the tests. And this is what I found:
If the Directory name is 25 characters or less long it works. It it is 26
characters or more, it doesn't. And so far it doesn't matter what the
Directory is called, only how long its name is determines whether the
Release version of the program (2 directory-levels lower inside it) will
die or not.
Note that the DEBUG version works no matter what the Project Directory is
called, and Release only works if the Project Directory name is 25
characters or less in length. Actually, it is probably more tied into the
LENGTH of the FULL PATH name to the application, which is used INTERNALLY
by the stuff supporting my code (i.e., the OS or .NET Framework).
How long is the "full path"? There is a limit at around 256 characters.
>
Does that sound like INTENDED BEHAVIOR to you? Sorry, but I'm pretty sure
this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :)
[==Peter==]
PS - I can assure you this has nothing to do with my code. The only time
my code accesses files is in the very beginning, where it simply loads in
image files into bitmaps (Bitmap^ bm = gcnew Bitmap( "filename") ;) and
does ZERO directory manipulation. All my files are assumed to be in the
same directory as the application's 'exe' file. And nothing is full path,
or else I couldn't change the directory path at all for it to work. And
since it always works in Debug version under the SAME Project Directory
name even if it fails under Release, well,....
PS - My program does nothing fancy, and accesses all files via relative to
the application
"David Lowndes" <Da****@example .invalidwrote in message
news:1h******** *************** *********@4ax.c om...
>In more detail:
Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release DIES!!
I'm thinking it has something to do with the symbols or spaces I use in
the
project directory name, or its length. Haven't experimented to tell one
way
or another.
I suggest you do those tests.
>>>This HAS to be a bug in the OS (operating system)!!!
I doubt it - do more tests - debug it in a folder name that gives rise
to the problem.
Dave
>>How long is the "full path"? There is a limit at around 256 characters.
Yup, I think that's it!
I made the directory name long enough my program didn't work. Then I moved
the entire directory WITH THE SAME NAME to the root directory so it would
shorten the full path name length. NOW the application works even though I
changed absolutely nothing (it was not a bug in my code).
Thus, it indeed seems to be that the full path name is too long and that was
the problem.
But this brings up another problem. WHY does the operating system let me
create a directory with a path name that is too long? Shouldn't VS notice
this too, and at least report it, since it created the Debug and Release
directories for me?
And, even worse, how many people have phoned into customer support on
consumer software becuase they installed into a place that had too long a
full path, even though the application is working fine? And why no WARNING,
such as "you are attempting to create a directory with a full path name
greater than 256 characters"?
So I feel the OS needs to be changed somehow to account for this 'hidden'
limitation. At least very least there should be some kind of warning as I
described. I mean, do you think the public at large is aware of this? Heck,
I didn't even know it, and I've been writing software using VS for many,
many years.
THANX BEN!!!! :)
[==Peter==]
"Ben Voigt [C++ MVP]" <rb*@nospam.nos pamwrote in message
news:eT******** ********@TK2MSF TNGP02.phx.gbl. ..
>
"Peter Oliphant" <po*******@roun dtripllc.comwro te in message
news:%2******** *******@TK2MSFT NGP05.phx.gbl.. .
>>I suggest you do those tests
OK, I did the tests. And this is what I found:
If the Directory name is 25 characters or less long it works. It it is 26
characters or more, it doesn't. And so far it doesn't matter what the
Directory is called, only how long its name is determines whether the
Release version of the program (2 directory-levels lower inside it) will
die or not.
Note that the DEBUG version works no matter what the Project Directory is
called, and Release only works if the Project Directory name is 25
characters or less in length. Actually, it is probably more tied into the
LENGTH of the FULL PATH name to the application, which is used INTERNALLY
by the stuff supporting my code (i.e., the OS or .NET Framework).
How long is the "full path"? There is a limit at around 256 characters.
>>
Does that sound like INTENDED BEHAVIOR to you? Sorry, but I'm pretty sure
this is a VS or OS BUG (or a hidden restriction I'm not aware of)... :)
[==Peter==]
PS - I can assure you this has nothing to do with my code. The only time
my code accesses files is in the very beginning, where it simply loads in
image files into bitmaps (Bitmap^ bm = gcnew Bitmap( "filename") ;) and
does ZERO directory manipulation. All my files are assumed to be in the
same directory as the application's 'exe' file. And nothing is full path,
or else I couldn't change the directory path at all for it to work. And
since it always works in Debug version under the SAME Project Directory
name even if it fails under Release, well,....
PS - My program does nothing fancy, and accesses all files via relative
to the application
"David Lowndes" <Da****@example .invalidwrote in message
news:1h******* *************** **********@4ax. com...
>>In more detail:
Directory name: ...\Project Demo\Release Works!
Directory name: ...\Project DemoXXX\Release Works!
Directory name: ...\Project Demo - 10-25-2007\Release DIES!!
I'm thinking it has something to do with the symbols or spaces I use in
the
project directory name, or its length. Haven't experimented to tell one
way
or another.
I suggest you do those tests.
This HAS to be a bug in the OS (operating system)!!!
I doubt it - do more tests - debug it in a folder name that gives rise
to the problem.
Dave
Peter Oliphant wrote:
So I feel the OS needs to be changed somehow to account for this
'hidden' limitation. At least very least there should be some kind of
warning as I described. I mean, do you think the public at large is
aware of this? Heck, I didn't even know it, and I've been writing
software using VS for many, many years.
I agree, FWIW. The MAX_PATH limitation is completely ridiculous for a modern
machine. The core OS will support paths, file names and directory names up
to 32K characters, but the Win32 API is still stuck at 260 characters for
most purposes. It's just DOS legacy cruft still getting in our way after
all these years.
-cd
>I made the directory name long enough my program didn't work.
So, exactly how long was it?
Although 260 characters may be limiting for some, most software does
accommodate it (though there have been many cases where off by 1
errors have caused problems over the years).
I'd still be suspicious of a bug lurking in your code - you need to
accommodate path length limits, not crash.
Dave
I'd still be suspicious of a bug lurking in your code - you need to
accommodate path length limits, not crash.
That's impossible. How can my code prevent an end-user from creating the
directory from which he runs my code being less than a certain full path
name length, when my code isn't running until it is placed in the directory
from which it can't run?
I bet nothing you've ever written accounts for this, does it? If so, please
tell me how to write code that works without being executed?
I think you have to start trying to stop blaming ME!!! LOL
[==Peter==]
"David Lowndes" <Da****@example .invalidwrote in message
news:nt******** *************** *********@4ax.c om...
I made the directory name long enough my program didn't work.
So, exactly how long was it?
Although 260 characters may be limiting for some, most software does
accommodate it (though there have been many cases where off by 1
errors have caused problems over the years).
I'd still be suspicious of a bug lurking in your code - you need to
accommodate path length limits, not crash.
Dave
>I'd still be suspicious of a bug lurking in your code - you need to
>accommodate path length limits, not crash.
That's impossible.
How can you say that when you've not pin pointed where in your program
the crash is occurring? If you think it's an OS problem and aren't
bothered if you have a real problem, then carry on ignoring the
potential for a bug in your code.
Try not to take my cajoling you to investigate this issue personally -
we all make mistakes - I certainly do, but from experience I think the
problem is most likely to be in some code you're using. If you can
show us a reproducible case with some sample code that repros it and
shows it's an OS problem, I'll buy you a pint.
Dave This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics | |
by: Yannick Patois |
last post by:
Hi,
Under some naming conditions of module files, it seems that python lost
class static variables values.
It seems only to append when importing a "badly" named module that
itself import a module with a static variable in it (looks complex, but
see the example below, pretty simple):
First a working example:
<<<< file: aTest.py
|
by: Adal Chiriliuc |
last post by:
Hi.
I think there's a bug in the code which builds sys.path for Windows.
The default zip archive file name in the debug build of Python is
pythonXY_d.zip and not pythonXY.zip. I'm not sure if this is
intentional. The zip import PEP doesn't mention it, nor does it the
code implementing it (PC/getpathp.c)
You can see that on Unix the zip archive name does not depend on the
type of build (or so it says in the PEP below).
|
by: Emil Dotchevski |
last post by:
This code causes the compiler to allocade a *lot* of memory *very*
fast, and even when I hit ctrl+break it still takes about a minute for
my system to recover and start responding to user input again.
What is more strange is the workarounds that prevent this compiler bug
from occuring.
For example, making the 'l' object a type (by adding a typedef at the
beginning of the last line) inhibits the bug.
|
by: Wayne Smith |
last post by:
I've come up against a major headache that I can't seem to find a solution
for but I'm sure there must be a workaround and I would really be grateful
of any help.
I'm currently building a web site for a small club I belong to and one of
the features I would like to include is the ability to allow users to upload
image files.
unfortunately the servers web root www folder only allows READ and EXECUTE
permissions, which makes it...
|
by: ELINTPimp |
last post by:
Hello all,
Have a really interesting problem (at least to me) with my
upload_file() function. I have it working now, with a bit of a work
around, but would like to know what everyone thinks in regards to this
being a bug or perhaps my ignorance. Basically the function takes two
arguments, one is the desired file path I want the upload file to be
moved to, and the second is an arbitrary integer. If the file doesn't
already exist, the...
| | |
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However, people are often confused as to whether an ONU can Work As a Router. In this blog post, we’ll explore What is ONU, What Is Router, ONU & Router’s main usage, and What is the difference between ONU and Router. Let’s take a closer look !
Part I. Meaning of...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can effortlessly switch the default language on Windows 10 without reinstalling. I'll walk you through it.
First, let's disable language synchronization. With a Microsoft account, language settings sync across devices. To prevent any complications,...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers, it seems that the internal comparison operator "<=>" tries to promote arguments from unsigned to signed.
This is as boiled down as I can make it.
Here is my compilation command:
g++-12 -std=c++20 -Wnarrowing bit_field.cpp
Here is the code in...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows Update option using the Control Panel or Settings app; it automatically checks for updates and installs any it finds, whether you like it or not. For most users, this new feature is actually very convenient. If you want to control the update process,...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing, and deployment—without human intervention. Imagine an AI that can take a project description, break it down, write the code, debug it, and then launch it, all on its own....
Now, this would greatly impact the work of software developers. The idea...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new presenter, Adolph Dupré who will be discussing some powerful techniques for using class modules.
He will explain when you may want to use classes instead of User Defined Types (UDT). For example, to manage the data in unbound forms.
Adolph will...
| | |
by: TSSRALBI |
last post by:
Hello
I'm a network technician in training and I need your help.
I am currently learning how to create and manage the different types of VPNs and I have a question about LAN-to-LAN VPNs.
The last exercise I practiced was to create a LAN-to-LAN VPN between two Pfsense firewalls, by using IPSEC protocols.
I succeeded, with both firewalls in the same network. But I'm wondering if it's possible to do the same thing, with 2 Pfsense firewalls...
|
by: muto222 |
last post by:
How can i add a mobile payment intergratation into php mysql website.
|
by: bsmnconsultancy |
last post by:
In today's digital era, a well-designed website is crucial for businesses looking to succeed. Whether you're a small business owner or a large corporation in Toronto, having a strong online presence can significantly impact your brand's success. BSMN Consultancy, a leader in Website Development in Toronto offers valuable insights into creating effective websites that not only look great but also perform exceptionally well. In this comprehensive...
| |
