I’ve also seen this fail; the first time was an installer that searched
for “previous versions of this project”.
The most recent time I saw was with Adobe Premier Pro, where a tree full
of video capture information couldn’t be accessed from the tool - the
user could browse to it, but then the tool would crash because the path
name was too big.
Were I writing an application, I’d be cognizant of this possibility
because it leads to an unsatisfactory user experience. However, I’ve
been thoroughly “set right” by others within this group - being advised
that it is perfectly reasonable for an application to exhibit mysterious
behavior by not allowing users to open paths that can actually be seen
and manipulated by Explorer.
I don’t like things that create mysterious failures, but I’m a kernel
guy, not an application guy, so my mysterious failures are spectacular
and visible to everyone.
Regards,
Tony
Tony Mason
Consulting Partner
OSR Open Systems Resources, Inc.
http://www.osr.com
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ricardo Vargas
Sent: Friday, May 12, 2006 4:31 PM
To: ntfsd redirect
Subject: Re:[ntfsd] hiding directories and files using OS level support
features [was: sid and process name lenghts]
“Tony Hoyle” wrote in message news:xxxxx@ntfsd…
> simply to open files. This needs to be fixed. How many developers
even
> know that hack exists?
the ones that read the documentation?
> Nobody is talking about infinite loops or crashing… where did you
get
> that from?
From code that I have seen of apps thinking that the path cannot exceed
MAX_PATH
Ricardo
—
Questions? First check the IFS FAQ at
https://www.osronline.com/article.cfm?id=17
You are currently subscribed to ntfsd as: xxxxx@osr.com
To unsubscribe send a blank email to xxxxx@lists.osr.com