Prev: No license to use this functionality
Next: XML displays in console but not in text boxes
From: Karl E. Peterson on 3 Jul 2008 21:13
Larry Serflaten wrote:
> "Karl E. Peterson" <karl(a)mvps.org> wrote
>> > Its not impossible, only difficult. The image below shows an
>> > actual listing on my W2K system...
>>
>> You must've cheated?! <g> Got a space in there, or something?
>
> Yes, in effect I cheated, I simply renamed an already existing folder
> to NUL using the technique at the bottom of the Naming a File page.
> (preceeded full path with \\.\)
>
> Ref: http://msdn.microsoft.com/en-us/library/aa365247.aspx
>
> I could not delete the folder, (tried it to see if I could) and had to
> rename it again to delete.

That's a pretty good trick... :-)
--
..NET: It's About Trust!
http://vfred.mvps.org


From: "Jialiang Ge [MSFT]" on 3 Jul 2008 06:48
Hello Karl

I get the symptom reproduced with your VB6 code. In order to see what
handle is added into the process, I use Process Explorer
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
to view the handle list.

When Command1 is clicked, process explorer shows that an additional File
Handle is added named as �C:\? If I click on Command1 again, this handle is
closed first, then reopened. If I click on Command2, the handle is closed
and the handle count is deducted by one. This behavior can be consistently
reproduced.

I will ask the language team for their explanation. Karl, would you please
let me know whether this behavior of Dir has any business impact on your
product?

Regards,
Jialiang Ge (jialge(a)online.microsoft.com, remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msdnmg(a)microsoft.com.

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================

From: Mike Williams on 4 Jul 2008 02:09
""Jialiang Ge [MSFT]"" <jialge(a)online.microsoft.com> wrote in message
news:Ofzqy%23Y3IHA.1624(a)TK2MSFTNGHUB02.phx.gbl...

> Regards,
> Jialiang Ge (jialge(a)online.microsoft.com, remove 'online.')
> Microsoft Online Community Support
> =================================================
> Delighting our customers is our #1 priority.

I was feeling a little bit down today, but you've cheered me up no end. It
really is comforting to know that people from Micro$oft are out there doing
their very best to delight us ;-)

Mike


From: Bob O`Bob on 4 Jul 2008 02:53
Jialiang Ge [MSFT] wrote:

> I will ask the language team for their explanation. Karl, would you please
> let me know whether this behavior of Dir has any business impact on your
> product?


ha!


"the language team"


Could you possibly BE any more out of touch with reality?






Bob
--
From: Tony Proctor on 4 Jul 2008 04:23
>> My test (top post) seems to corroborate those results. What did you use
>> to make your determination?

Just an educated guess really Karl. It's pretty easy to see that Dir$() is
stateful, and keeps a handle to the directory open while is returns file
names from it. Hence, if it isn't called to exhaustion (i.e. where it
returns a blank) then that handle gets left behind and keeps the directory
locked. Another way to force the release of the handle is to move it
somewhere else (i.e. search a different directory), or better still search
something that's always going to be there but cannot be locked (hence the
use of the "nul" device)

Tony Proctor

"Karl E. Peterson" <karl(a)mvps.org> wrote in message
news:eR3KodT3IHA.1428(a)TK2MSFTNGP06.phx.gbl...
> Tony Proctor wrote:
>> Karl, you may be thinking of my original post on this subject:
>> http://groups.google.ie/group/microsoft.public.vb.general.discussion/msg/5e589d1e61920a5e?hl=en
>
> Yes! That's the post I was searching for.
>
> My test (top post) seems to corroborate those results. What did you use
> to make your determination?
>
> What I also found interesting is the number of folks suggesting using nul
> to test for directory existance, too. And, that not only does this seem
> to work, but it also clears the cached search handle. Whether the
> directory exists or not!
>
> One thing in your post I didn't test (yet)...
>
>> There are quite a few posts acknowledging that Dir() has this unfortunate
>> side-effect of locking the directory until the search has been exhausted
>> Karl
>> (i.e. blank has been returned). It's a real PIA if you want to
>> prematurely
>> terminate the search, based on some additional criteria.
>
> That implies that if you loop through until Dir() returns just an empty
> string, that VB does actually call FindClose at that point? Something I
> think I'll try to test as well.
>
> Thanks... Karl
> --
> .NET: It's About Trust!
> http://vfred.mvps.org
>


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: No license to use this functionality
Next: XML displays in console but not in text boxes