Bug in the class 'File'???

My name is Jonathon Spaeth.

I primarily have worked with VisualAge for Smalltalk and have adopted
Dolphin recently as it seems to be a competetivly mature product now.  I
have experienced what I believe to be a bug in the class library;
specifically in the File class.  File has a class method called forall:in:do
which iterates through all the subfolders in the filesystem and passes each
file struct to the block passed as the do:.  However, I am running Windows
2000 and receive a vm exception when passing in the path to the root folder
on any drive to the in: part of forall:in:do.  For example:

File forAll: '*.txt' in: 'd:\' do: [ :each | ].

This properly iterates through all the subfolders.  In fact if the block
[ :each | MessageBox errorMsg: each path. ]
is used as an argument instead of the above empty block, the method properly
displays a message box for each file matching *.txt anywhere underneath d:\.
However, the bug is to be found when the method recurses to the special
windows 2000 folder called 'System Volume Information' found on every
windows 2000 volume.  This folder doesn't allow the same access that normal
folders do and a vm exception is thrown telling me access has been denied.
The following string represents the error as reported from the KernelLibrary
class returned using the systemError message:
a KernelLibrary(16r77E80000 - 'C:\WINNT\system32\KERNEL32.dll')

This seems to me to be an issue regarding the fact that 'System Volume
Information' is a specially-controlled folder within windows.  The smalltalk
methods seem to be working properly except for handling a very common
condition, that of not being able to access a folder which is guaranteed to
exist on a Windows 2000 computer.  This prohibits recursively performing a
search for files matching a specified filter from the root folder without
causing this vm exception, breaking execution of the code.

In my debugging, I tried changing many of the variables outside the
smalltalk system, including modifying the permissions of the offending
folder to no avail.  It seems to me that the 'System Volume Information' is
a specially-controlled type of folder that should not cause a vm exception
any time an object attempts to access it.

It also seems to that I have a choice between one of two basic strategies
for a solution to this problem.  The first and simplest is to not use that
method or perform the recursive logic myself, checking all folders for the
name 'System Volume Information' and skip that folder such that it is not
accessed in the recursive search.  This approach has the advantage of being
the quickest to implement and I have already modified my code to not rely on
this seemingly broken method.  However, it is not a fix to the problem,
rather a workaround.  I believe a true fix to any bugs must be coordinated
with object arts and have submitted this one, but newsgroups commonly offer
quicker feedback than does technical support :).

If anybody has experienced this particular bug, please let me know, even if
no patch exists, I'ld like to confirm the existence of the same bug by an
independent individual (none of my programming friends are smalltalk-savy).

Jonathon,

> If anybody has experienced this particular bug, please let me know, even
if
> no patch exists, I'ld like to confirm the existence of the same bug by an
> independent individual (none of my programming friends are
smalltalk-savy).

I tried it on my XP system and received exactly the same error.

My initial reaction, fix wise, would be to ask whether the default action
for File>>forAll:in: should recurse through System folders as well, as it
currently does.  There could be a case for restricting it to "normal"
directories and folders, maybe controlled with an additional parameter.

I was also going to suggest that you have a look at the IFileSystem class,
part of the ActiveX scripting control.  I tried it though and found that
this seems to exhibit a similar behaviour - by default the #getFolders
method answers "System Volume Information" as a valid sub folder but sending
#files or #subFolders to the resulting object results in an error.

Regards
    Ian

Ian

Thanks for your help.  Upon further investigation I found that the problem
is not that the 'System Volume Information' is a special folder, but rather,
the default permissions assigned to it.  If you remove the permissions from
any folder in your system, you will receive the same smalltalk vm message.

Jon

"Ian Bartholomew" <[hidden email]> wrote in message
news:SBab9.2199$571.164206@wards...
> Jonathon,
>
> > If anybody has experienced this particular bug, please let me know, even
> if
> > no patch exists, I'ld like to confirm the existence of the same bug by
an sending
> #files or #subFolders to the resulting object results in an error.
>
> Regards
>     Ian
>
>

Jonathon

You wrote in message
news:xSqb9.3300$[hidden email]...
> ...
> Thanks for your help.  Upon further investigation I found that the problem
> is not that the 'System Volume Information' is a special folder, but
rather,
> the default permissions assigned to it.  If you remove the permissions
from
> any folder in your system, you will receive the same smalltalk vm message.

Yes, I think the method needs to handle ERROR_ACCESS_DENIED (code 5) in the
same way that it handles ERROR_FILE_NOT_FOUND when checking the error return
code from the FindFirstFile API, i.e. it should treat this as a
non-exceptional condition and exit making no attempt to enumerate the files
in the folder to which access is not permitted.

BTW: I don't really understand what you mean by a "vm message" or the "vm
exception" you refer to in your other posting. Exceptions are raised,
propagated and handled entirely by Smalltalk code in Dolphin.

Regards

Blair