Long paths

Ok, I have an access module which builds an index of directories in
the subtree of a user-selected directory/drive. Then, it goes through
those and builds another index of all the files in those directories.
I'm using the FileSystemObject just for clean code. Here's the
problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.

The fso is reporting the correct number of files, but for the files
that exceed the limit, it acts like they're not even there. No errors
are raised, nothing.

I've tried this in VB6, but again nothing. I was told the kernel has
some API's I can use, but honestly, I am not that well versed in API
usage.

Bottom line, I need to be able to capture the long path of every
file. I can use the shortpath for my metadata extraction, etc, but
for the people who use the output of this, I do need to capture the
"windows explorer" name.

Here's an example of a filepath that's too far out: (This is an actual
file that I generated for testing)

X:\shared\username
\New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdiofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
\adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt

Pegasus
Mon Jun 30 12:11:18 CDT 2008


"krazymike" <krazymike@gmail.com> wrote in message
news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...
> Ok, I have an access module which builds an index of directories in
> the subtree of a user-selected directory/drive. Then, it goes through
> those and builds another index of all the files in those directories.
> I'm using the FileSystemObject just for clean code. Here's the
> problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.
>
> The fso is reporting the correct number of files, but for the files
> that exceed the limit, it acts like they're not even there. No errors
> are raised, nothing.
>
> I've tried this in VB6, but again nothing. I was told the kernel has
> some API's I can use, but honestly, I am not that well versed in API
> usage.
>
> Bottom line, I need to be able to capture the long path of every
> file. I can use the shortpath for my metadata extraction, etc, but
> for the people who use the output of this, I do need to capture the
> "windows explorer" name.
>
> Here's an example of a filepath that's too far out: (This is an actual
> file that I generated for testing)
>
> X:\shared\username
> \New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdiofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
> \adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt

There are a few applications that can process the full NTFS path
length of some 32,000 characters (I think), e.g. ntbackup.exe,
robocopy.exe or iexplore.exe. AFAIK, neither cscript.exe nor
wscript.exe is among them.

krazymike
Mon Jun 30 12:21:21 CDT 2008

Ok, can I call these apps and get something returned? This data is
going into an mdb, so just being able to access them isn't enough.

On Jun 30, 12:11=A0pm, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
> "krazymike" <krazym...@gmail.com> wrote in message
>
> news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...
>
>
>
> > Ok, I have an access module which builds an index of directories in
> > the subtree of a user-selected directory/drive. =A0Then, it goes throug=
h
> > those and builds another index of all the files in those directories.
> > I'm using the FileSystemObject just for clean code. =A0Here's the
> > problem I'm hitting. =A0I'm hitting the 260 character MAX_PATH limit.
>
> > The fso is reporting the correct number of files, but for the files
> > that exceed the limit, it acts like they're not even there. =A0No error=
s
> > are raised, nothing.
>
> > I've tried this in VB6, but again nothing. =A0I was told the kernel has
> > some API's I can use, but honestly, I am not that well versed in API
> > usage.
>
> > Bottom line, I need to be able to capture the long path of every
> > file. =A0I can use the shortpath for my metadata extraction, etc, but
> > for the people who use the output of this, I do need to capture the
> > "windows explorer" name.
>
> > Here's an example of a filepath that's too far out: (This is an actual
> > file that I generated for testing)
>
> > X:\shared\username
> > \New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdi=
ofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
> > \adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt
>
> There are a few applications that can process the full NTFS path
> length of some 32,000 characters (I think), e.g. ntbackup.exe,
> robocopy.exe or iexplore.exe. AFAIK, neither cscript.exe nor
> wscript.exe is among them.

Pegasus
Mon Jun 30 13:07:30 CDT 2008

You could execute robocopy.exe /L and monitor its screen output.
A good long-term strategy would be to educate your users to put
their data into their files, not into their file/folder names.


"krazymike" <krazymike@gmail.com> wrote in message
news:f7416f09-1445-4aac-a5dd-8d6727516965@79g2000hsk.googlegroups.com...
Ok, can I call these apps and get something returned? This data is
going into an mdb, so just being able to access them isn't enough.

On Jun 30, 12:11 pm, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
> "krazymike" <krazym...@gmail.com> wrote in message
>
> news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...
>
>
>
> > Ok, I have an access module which builds an index of directories in
> > the subtree of a user-selected directory/drive. Then, it goes through
> > those and builds another index of all the files in those directories.
> > I'm using the FileSystemObject just for clean code. Here's the
> > problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.
>
> > The fso is reporting the correct number of files, but for the files
> > that exceed the limit, it acts like they're not even there. No errors
> > are raised, nothing.
>
> > I've tried this in VB6, but again nothing. I was told the kernel has
> > some API's I can use, but honestly, I am not that well versed in API
> > usage.
>
> > Bottom line, I need to be able to capture the long path of every
> > file. I can use the shortpath for my metadata extraction, etc, but
> > for the people who use the output of this, I do need to capture the
> > "windows explorer" name.
>
> > Here's an example of a filepath that's too far out: (This is an actual
> > file that I generated for testing)
>
> > X:\shared\username
> > \New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdiofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
> > \adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt
>
> There are a few applications that can process the full NTFS path
> length of some 32,000 characters (I think), e.g. ntbackup.exe,
> robocopy.exe or iexplore.exe. AFAIK, neither cscript.exe nor
> wscript.exe is among them.

Howard
Mon Jun 30 13:59:44 CDT 2008

You need to use the Unicode version of API calls.

Start by looking at the CreateFileW, the Unicode version of CreateFile.

Ralph
Mon Jun 30 14:06:14 CDT 2008


"krazymike" <krazymike@gmail.com> wrote in message
news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...
> Ok, I have an access module which builds an index of directories in
> the subtree of a user-selected directory/drive. Then, it goes through
> those and builds another index of all the files in those directories.
> I'm using the FileSystemObject just for clean code. Here's the
> problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.
>
> The fso is reporting the correct number of files, but for the files
> that exceed the limit, it acts like they're not even there. No errors
> are raised, nothing.
>
> I've tried this in VB6, but again nothing. I was told the kernel has
> some API's I can use, but honestly, I am not that well versed in API
> usage.
>

This limitation is limited to the ANSI (or 'A') versions of the API
functions. You can work with longer paths if you use the UNICODE or 'W'
versions: eg. use
... Alias "FindFirstFileW" instead of Alias "FindFirstFileA"
which is how you will find many VB/WinAPI calls declared. This is can be
confusing in some examples because for back-ward compatibility
"FindFirstFile" maps to "FindFirstFileA", and thus the 'A' or 'W' may be
missing in the Declare.
Take a look at this example:
http://www.dbforums.com/showthread.php?t=979095
(It uses the 'A' versions. Simply make the change yourself and then test it
against your data/paths.)

Note the explanation on using the "\\?\" hack if you want to pass a long
path.

hth
-ralph

krazymike
Mon Jun 30 14:26:22 CDT 2008

Unfortunately, I'm not dealing with users, as such. I work in a law
firm, and client's hard drives are often copied to network locations.
Add the network path to the file path of the files, and you get a lot
of 300+ character paths.

So, even if we educated the proper people, putting these files on the
network would negate their albeit proper practices. Second, we could
never educate every user we will deal with, as we cannot predict whom
our clients will be.

On Jun 30, 1:07=A0pm, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
> You could execute robocopy.exe /L and monitor its screen output.
> A good long-term strategy would be to educate your users to put
> their data into their files, not into their file/folder names.
>
> "krazymike" <krazym...@gmail.com> wrote in message
>
> news:f7416f09-1445-4aac-a5dd-8d6727516965@79g2000hsk.googlegroups.com...
> Ok, can I call these apps and get something returned? =A0This data is
> going into an mdb, so just being able to access them isn't enough.
>
> On Jun 30, 12:11 pm, "Pegasus \(MVP\)" <I....@fly.com.oz> wrote:
>
> > "krazymike" <krazym...@gmail.com> wrote in message
>
> >news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...=

>
> > > Ok, I have an access module which builds an index of directories in
> > > the subtree of a user-selected directory/drive. Then, it goes through
> > > those and builds another index of all the files in those directories.
> > > I'm using the FileSystemObject just for clean code. Here's the
> > > problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.
>
> > > The fso is reporting the correct number of files, but for the files
> > > that exceed the limit, it acts like they're not even there. No errors
> > > are raised, nothing.
>
> > > I've tried this in VB6, but again nothing. I was told the kernel has
> > > some API's I can use, but honestly, I am not that well versed in API
> > > usage.
>
> > > Bottom line, I need to be able to capture the long path of every
> > > file. I can use the shortpath for my metadata extraction, etc, but
> > > for the people who use the output of this, I do need to capture the
> > > "windows explorer" name.
>
> > > Here's an example of a filepath that's too far out: (This is an actual=

> > > file that I generated for testing)
>
> > > X:\shared\username
> > > \New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa=
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdi=
ofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
> > > \adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt
>
> > There are a few applications that can process the full NTFS path
> > length of some 32,000 characters (I think), e.g. ntbackup.exe,
> > robocopy.exe or iexplore.exe. AFAIK, neither cscript.exe nor
> > wscript.exe is among them.

Klatuu
Mon Jun 30 14:28:07 CDT 2008

Try using Application.FileSearch instead of FSO.
The codinging is similar, but it is native to Access. FSO is an Office
object that is known to be flaky at times.
--
Dave Hargis, Microsoft Access MVP


"krazymike" wrote:

> Ok, I have an access module which builds an index of directories in
> the subtree of a user-selected directory/drive. Then, it goes through
> those and builds another index of all the files in those directories.
> I'm using the FileSystemObject just for clean code. Here's the
> problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.
>
> The fso is reporting the correct number of files, but for the files
> that exceed the limit, it acts like they're not even there. No errors
> are raised, nothing.
>
> I've tried this in VB6, but again nothing. I was told the kernel has
> some API's I can use, but honestly, I am not that well versed in API
> usage.
>
> Bottom line, I need to be able to capture the long path of every
> file. I can use the shortpath for my metadata extraction, etc, but
> for the people who use the output of this, I do need to capture the
> "windows explorer" name.
>
> Here's an example of a filepath that's too far out: (This is an actual
> file that I generated for testing)
>
> X:\shared\username
> \New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdiofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
> \adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt
>

Mike
Mon Jun 30 14:51:11 CDT 2008

"krazymike" <krazymike@gmail.com> wrote in message
news:c4714faa-7b55-46fd-8d17-81968a76e7e4@f36g2000hsa.googlegroups.com...

> Unfortunately, I'm not dealing with users, as such.
> I work in a law firm, and client's hard drives are often
> copied to network locations. Add the network path to
> the file path of the files, and you get a lot of 300+
> character paths.

Agreed. It is not always possible, and very rarely advisable, to attempt to
force your users into behaving in a specific way. The same kind of "long
name" problems often also occur with printer devicenames, which can
effectively be an almost unlimited length in all 32 bit versions of Windows
but which require you to jump through a few hoops in order to dig out their
long names when showing an API printer dialog.

Mike

Albert
Mon Jun 30 15:26:27 CDT 2008

Keep in mind that a standard ms-access feld is limited to 255 chars, and
perhaps you need to use a memo field to store the results????

In otther words, are you use its th fso that casuing the problem here, or is
it perhaps you exceeiding the limites of a stadnard text field?

here is the follwing code I use to walk a direcotry using the dir
command....I do't belive it suffers from the 255 char limit...

Sub dirTest()

Dim dlist As New Collection
Dim startDir As String
Dim i As Integer

startDir = "C:\access\"
Call FillDir(startDir, dlist)

MsgBox "there are " & dlist.Count & " in the dir"

' lets printout the stuff into debug window for a test

For i = 1 To dlist.Count
Debug.Print dlist(i)
Next i

End Sub

Sub FillDir(startDir As String, strFil As String, dlist As Collection)

' build up a list of files, and then
' add add to this list, any additinal
' folders

Dim strTemp As String
Dim colfolders As New Collection
Dim vFolderName As Variant

strTemp = Dir(startDir & strFil)

Do While strTemp <> ""
dlist.Add startDir & strTemp
strTemp = Dir
Loop

' now build a list of additional folders
strTemp = Dir(startDir & "*.*", vbDirectory)

Do While strTemp <> ""
If (GetAttr(startDir & strTemp) And vbDirectory) = vbDirectory Then
If (strTemp <> ".") And (strTemp <> "..") Then
colfolders.Add strTemp
End If
End If
strTemp = Dir
Loop

' now process each folder (recursion)
For Each vFolderName In colfolders
Call FillDir(startDir & vFolderName & "\", strFil, dlist)
Next vFolderName

End Sub

Sub FillDir(startDir As String, dlist As Collection)

' build up a list of files, and then
' add add to this list, any additional
' folders

Dim strTemp As String
Dim colFolders As New Collection
Dim vFolderName As Variant

strTemp = Dir(startDir)

Do While strTemp <> ""
dlist.Add startDir & strTemp
strTemp = Dir
Loop

' now build a list of additional folders
strTemp = Dir(startDir & "*.", vbDirectory)

Do While strTemp <> ""
If (strTemp <> ".") And (strTemp <> "..") Then
colFolders.Add strTemp
End If
strTemp = Dir
Loop

' now process each folder (recursion)
For Each vFolderName In colFolders
Call FillDir(startDir & vFolderName & "\", dlist)
Next vFolderName

End Sub


--
Albert D. Kallal (Access MVP)
Edmonton, Alberta Canada
pleaseNOOSpamKallal@msn.com

Mike
Mon Jun 30 16:10:44 CDT 2008

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in message
news:%23NRbT%23u2IHA.3544@TK2MSFTNGP05.phx.gbl...

> [Addressed to the OP] Keep in mind that a standard
> ms-access feld is limited to 255 chars, and perhaps you
> need to use a memo field to store the results???? . . .
> here is the follwing code I use to walk a direcotry using
> the dir command....I do't belive it suffers from the 255
> char limit...

Actually the maximum file name size limit appears to be heavily embedded
into the Windows OS. I'm using Windows Vista Ultimate and the OS (or at
least Windows Explorer) prevents me even from manually renaming a file such
that its total path length is greater than about 259 characters. And when I
make the name as long as the OS will permit (such as "c:\temp\a very long
file name . . . . ."and I later try to move that file into a directory that
has a longer path name (such as my desktop, for example) the system prevents
me from doing so, informing me that "The filename is too long for the
destination folder" and advising me to either shorten the filename and try
agin or alternatively choose a destination folder that has a shorter path.
And if I "cheat a little" by renaming "c:\temp" folder to "c:\t" (which
permits me to add a few extra characters to the filename) and if I then
cange it back to "c:\temp" after adding those few extra charcaters and then
use the code you posted to run through c:\temp I get a "File Not Found"
error when it attempts to access the file with the long name.

So, it looks as though this file name length limitation is more heavily
embedded into the OS than I at first thought it might be.

Mike

Tom
Mon Jun 30 16:34:29 CDT 2008

On 2008-06-30, Mike Williams <mikea@whiskyandCoke.com> wrote:
> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in message
> news:%23NRbT%23u2IHA.3544@TK2MSFTNGP05.phx.gbl...
>
>> [Addressed to the OP] Keep in mind that a standard
>> ms-access feld is limited to 255 chars, and perhaps you
>> need to use a memo field to store the results???? . . .
>> here is the follwing code I use to walk a direcotry using
>> the dir command....I do't belive it suffers from the 255
>> char limit...
>
> Actually the maximum file name size limit appears to be heavily embedded
> into the Windows OS. I'm using Windows Vista Ultimate and the OS (or at
> least Windows Explorer) prevents me even from manually renaming a file such
> that its total path length is greater than about 259 characters. And when I
> make the name as long as the OS will permit (such as "c:\temp\a very long
> file name . . . . ."and I later try to move that file into a directory that
> has a longer path name (such as my desktop, for example) the system prevents
> me from doing so, informing me that "The filename is too long for the
> destination folder" and advising me to either shorten the filename and try
> agin or alternatively choose a destination folder that has a shorter path.
> And if I "cheat a little" by renaming "c:\temp" folder to "c:\t" (which
> permits me to add a few extra characters to the filename) and if I then
> cange it back to "c:\temp" after adding those few extra charcaters and then
> use the code you posted to run through c:\temp I get a "File Not Found"
> error when it attempts to access the file with the long name.
>
> So, it looks as though this file name length limitation is more heavily
> embedded into the OS than I at first thought it might be.
>
> Mike
>
>
>

Many of the Unicode api's allow you to access paths up to 32,000
characters (NTFS maximum path length) - but, you have to use the unicode
version of the api and prefix the path with \\?\ to tell it to use the long
path:

"\\?\C:\........\....\..."

Otherwise, they use MAX_PATH, which is defined as 260 - 259 chars + a null
terminator.

--
Tom Shelton

Mike
Mon Jun 30 16:57:57 CDT 2008

"Tom Shelton" <tom_shelton@comcastXXXXXXX.net> wrote in message
news:09KdnTmAzIb4zPTVnZ2dnUVZ_jSdnZ2d@comcast.com...

> Many of the Unicode api's allow you to access paths
> up to 32,000 characters (NTFS maximum path length)
> - but, you have to use the unicode version of the api and
> prefix the path with \\?\ to tell it to use the long path:

Yes, I'm sure they do. And in fact I've already been informed that they do.
But I was merely commenting on how deeply the "limited character length path
and file name" is embedded into the Windows OS, to the point that even in
Vista Ultimate a user or even an administrator cannot manually create a long
file name using the standard "Windows Explorer" methods available to users.

Mike

Karl
Mon Jun 30 18:57:57 CDT 2008

krazymike wrote:
> Unfortunately, I'm not dealing with users, as such. I work in a law
> firm, and client's hard drives are often copied to network locations.
> Add the network path to the file path of the files, and you get a lot
> of 300+ character paths.

Seems like you could overcome this by simply sharing the folder from the server,
then attaching to it from the workstation?
--
.NET: It's About Trust!
http://vfred.mvps.org

Ron
Mon Jun 30 19:13:33 CDT 2008

Have you try'd to use the API GetShortPathName()

Here is the Declare:
Private Declare Function GetShortPathName Lib "kernel32.dll" _
Alias "GetShortPathNameA" (ByVal lpszLongPath As String, _
ByVal lpszShortPath As String, ByVal cchBuffer As Long) As Long

Here is a Function:
Public Function ShortName(strLongPath As String) As String
' Purpose Converts Long FileName to its Short FileName
Dim strShortPath As String
Dim Ret As Long
Const MAX_PATH = 260

If strLongPath = "" Then
Exit Function
End If
strShortPath = Space$(MAX_PATH)
Ret = GetShortPathName(strLongPath, strShortPath, MAX_PATH)
If Ret Then
ShortName = Left$(strShortPath, Ret)
End If
End Function


Rdub


"krazymike" <krazymike@gmail.com> wrote in message
news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...
> Ok, I have an access module which builds an index of directories in
> the subtree of a user-selected directory/drive. Then, it goes through
> those and builds another index of all the files in those directories.
> I'm using the FileSystemObject just for clean code. Here's the
> problem I'm hitting. I'm hitting the 260 character MAX_PATH limit.
>
> The fso is reporting the correct number of files, but for the files
> that exceed the limit, it acts like they're not even there. No errors
> are raised, nothing.
>
> I've tried this in VB6, but again nothing. I was told the kernel has
> some API's I can use, but honestly, I am not that well versed in API
> usage.
>
> Bottom line, I need to be able to capture the long path of every
> file. I can use the shortpath for my metadata extraction, etc, but
> for the people who use the output of this, I do need to capture the
> "windows explorer" name.
>
> Here's an example of a filepath that's too far out: (This is an actual
> file that I generated for testing)
>
> X:\shared\username
> \New_Folderaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaadfasdfasdfasdifuasdiofuyeasdkofuheasdkjfjheaskldjfheaskdfheaskdjfheaskldjfheaskdjfhasd
> \adsfdkjfheaskdjfheasldkjfheasdklfehasdfkljashdlfjksdfh.txt

Howard
Tue Jul 01 06:12:52 CDT 2008

"Mike Williams" <mikea@whiskyandCoke.com> wrote in message
news:u$FdYXv2IHA.2332@TK2MSFTNGP03.phx.gbl...
> "Albert D. Kallal" <PleaseNOOOsPAMmkallal@msn.com> wrote in message
> news:%23NRbT%23u2IHA.3544@TK2MSFTNGP05.phx.gbl...
>
> > [Addressed to the OP] Keep in mind that a standard
> > ms-access feld is limited to 255 chars, and perhaps you
> > need to use a memo field to store the results???? . . .
> > here is the follwing code I use to walk a direcotry using
> > the dir command....I do't belive it suffers from the 255
> > char limit...
>
> Actually the maximum file name size limit appears to be heavily embedded
> into the Windows OS. I'm using Windows Vista Ultimate and the OS (or at
> least Windows Explorer) prevents me even from manually renaming a file
such
> that its total path length is greater than about 259 characters. And when
I
> make the name as long as the OS will permit (such as "c:\temp\a very long
> file name . . . . ."and I later try to move that file into a directory
that
> has a longer path name (such as my desktop, for example) the system
prevents
> me from doing so, informing me that "The filename is too long for the
> destination folder" and advising me to either shorten the filename and try
> agin or alternatively choose a destination folder that has a shorter path.
> And if I "cheat a little" by renaming "c:\temp" folder to "c:\t" (which
> permits me to add a few extra characters to the filename) and if I then
> cange it back to "c:\temp" after adding those few extra charcaters and
then
> use the code you posted to run through c:\temp I get a "File Not Found"
> error when it attempts to access the file with the long name.
>
> So, it looks as though this file name length limitation is more heavily
> embedded into the OS than I at first thought it might be.

Yes, you have to use Unicode API calls.

krazymike
Tue Jul 01 11:04:50 CDT 2008

Ok, back to the original topic.

I used FindFirstFileA and FindNextFileA and was able to access a path
of 306 characters. Now, I need to cover the UNICODE characters which
may be in the file names. We get stuff from macs and linux machines
from time to time. As far as I understand, I should be able to change
the A to a W to use the unicode version. That doesn't work. I
prepended the "\\?\" to the path, and had no luck. I'm wondering if I
need some language packs installed to use unicode at all.

Any thoughts?

On Jul 1, 6:12=A0am, "Howard Kaikow" <kai...@standards.com> wrote:
> "Mike Williams" <mi...@whiskyandCoke.com> wrote in message
>
> news:u$FdYXv2IHA.2332@TK2MSFTNGP03.phx.gbl...
>
>
>
> > "Albert D. Kallal" <PleaseNOOOsPAMmkal...@msn.com> wrote in message
> >news:%23NRbT%23u2IHA.3544@TK2MSFTNGP05.phx.gbl...
>
> > > [Addressed to the OP] Keep in mind that a standard
> > > ms-access feld is limited to 255 chars, and perhaps you
> > > need to use a memo field to store the results???? =A0. . .
> > > here is the follwing code I use to walk a direcotry using
> > > the dir command....I do't belive it suffers from the 255
> > > char limit...
>
> > Actually the maximum file name size limit appears to be heavily embedde=
d
> > into the Windows OS. I'm using Windows Vista Ultimate and the OS (or at
> > least Windows Explorer) prevents me even from manually renaming a file
> such
> > that its total path length is greater than about 259 characters. And wh=
en
> I
> > make the name as long as the OS will permit (such as "c:\temp\a very lo=
ng
> > file name . . . . ."and I later try to move that file into a directory
> that
> > has a longer path name (such as my desktop, for example) the system
> prevents
> > me from doing so, informing me that "The filename is too long for the
> > destination folder" and advising me to either shorten the filename and =
try
> > agin or alternatively choose a destination folder that has a shorter pa=
th.
> > And if I "cheat a little" by renaming "c:\temp" folder to "c:\t" (which
> > permits me to add a few extra characters to the filename) and if I then
> > cange it back to "c:\temp" after adding those few extra charcaters and
> then
> > use the code you posted to run through c:\temp I get a "File Not Found"
> > error when it attempts to access the file with the long name.
>
> > So, it looks as though this file name length limitation is more heavily
> > embedded into the OS than I at first thought it might be.
>
> Yes, you have to use Unicode API calls.

krazymike
Tue Jul 01 12:58:45 CDT 2008

This worked just fine, but I'm trying to process Unicode chars in
filenames now, and the "W" version doesn't seem to be working.

Also, to address an issue brought up, my fields are, in fact, Memo.

On Jun 30, 2:06=A0pm, "Ralph" <nt_consultin...@yahoo.com> wrote:
> "krazymike" <krazym...@gmail.com> wrote in message
>
> news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@d45g2000hsc.googlegroups.com...
>
> > Ok, I have an access module which builds an index of directories in
> > the subtree of a user-selected directory/drive. =A0Then, it goes throug=
h
> > those and builds another index of all the files in those directories.
> > I'm using the FileSystemObject just for clean code. =A0Here's the
> > problem I'm hitting. =A0I'm hitting the 260 character MAX_PATH limit.
>
> > The fso is reporting the correct number of files, but for the files
> > that exceed the limit, it acts like they're not even there. =A0No error=
s
> > are raised, nothing.
>
> > I've tried this in VB6, but again nothing. =A0I was told the kernel has
> > some API's I can use, but honestly, I am not that well versed in API
> > usage.
>
> This limitation is limited to the ANSI (or 'A') versions of the API
> functions. You can work with longer paths if you use the UNICODE or 'W'
> versions: eg. use
> =A0... Alias "FindFirstFileW" instead of Alias "FindFirstFileA"
> which is how you will find many VB/WinAPI calls declared. This is can be
> confusing in some examples because for back-ward compatibility
> "FindFirstFile" maps to "FindFirstFileA", and thus the 'A' or 'W' may be
> missing in the Declare.
> Take a look at this example:http://www.dbforums.com/showthread.php?t=3D97=
9095
> (It uses the 'A' versions. Simply make the change yourself and then test =
it
> against your data/paths.)
>
> Note the explanation on using the "\\?\" hack if you want to pass a long
> path.
>
> hth
> -ralph

Karl
Tue Jul 01 13:20:25 CDT 2008

krazymike wrote:
> Ok, back to the original topic.
>
> I used FindFirstFileA and FindNextFileA and was able to access a path
> of 306 characters. Now, I need to cover the UNICODE characters which
> may be in the file names. We get stuff from macs and linux machines
> from time to time. As far as I understand, I should be able to change
> the A to a W to use the unicode version.

Right.

> That doesn't work.

Huh? You're a *developer* and you post a *user* error report?

> prepended the "\\?\" to the path, and had no luck. I'm wondering if I
> need some language packs installed to use unicode at all.
>
> Any thoughts?

Yeah. But I'll spare you most of them.

You need to understand Unimess, first. The way VB mangles the Unicode strings it
stores internally, when passing them externally, and vice-versa. To get Unicode
in/out of VB, you need to work directly with pointers. How are you declaring the
API(s) and their related structures? How are you filling the structures? How are
you reading what's returned?

"Doesn't work" doesn't even begin to provide the requisite clues.
--
.NET: It's About Trust!
http://vfred.mvps.org

krazymike
Tue Jul 01 15:10:33 CDT 2008

Thanks. That's a lot of help. You know it's people like you who make
it nearly impossible to get any help. Trying to make people look bad
and yourself good only serves to expose you as the jerk you clearly
are.

"Doesn't work" =3D hSearch gets value of -1 no matter what I do.

Prepending the \\?\ doesn't change anything. What I was told that my
code that works with the FindFirstFileA/FindNextFileA would work by
switching to the W implementation of these functions. I'm finding
that this is not the case.

I read somewhere that you need to pass the parameters to the W
implementations as UTF-16 strings, but I have yet to have any luck
with that either. The UTF-16 converter I found was returning null
strings. I tried using MultiByteToWideChar to generate a UTF-8, but I
don't think that's really doing much. The handler still receives the
-1 value.

I know this has to be possible, but perhaps not from VBA? If I can
get this working in vb6, that'd do fine, too. I'm just restricted
from using .Net in my department. Not my choice, just the way
"business" decisions are made sometimes.

On Jul 1, 1:20=A0pm, "Karl E. Peterson" <k...@mvps.org> wrote:
> krazymike wrote:
> > Ok, back to the original topic.
>
> > I used FindFirstFileA and FindNextFileA and was able to access a path
> > of 306 characters. =A0Now, I need to cover the UNICODE characters which
> > may be in the file names. =A0We get stuff from macs and linux machines
> > from time to time. =A0As far as I understand, I should be able to chang=
e
> > the A to a W to use the unicode version.
>
> Right.
>
> > That doesn't work.
>
> Huh? =A0You're a *developer* and you post a *user* error report?
>
> > prepended the "\\?\" to the path, and had no luck. =A0I'm wondering if =
I
> > need some language packs installed to use unicode at all.
>
> > Any thoughts?
>
> Yeah. =A0But I'll spare you most of them.
>
> You need to understand Unimess, first. =A0The way VB mangles the Unicode =
strings it
> stores internally, when passing them externally, and vice-versa. =A0To ge=
t Unicode
> in/out of VB, you need to work directly with pointers. =A0How are you dec=
laring the
> API(s) and their related structures? =A0How are you filling the structure=
s? =A0How are
> you reading what's returned?
>
> "Doesn't work" doesn't even begin to provide the requisite clues.
> --
> .NET: It's About Trust!
> =A0http://vfred.mvps.org

Karl
Tue Jul 01 15:32:11 CDT 2008

krazymike wrote:
> Thanks. That's a lot of help. You know it's people like you who make
> it nearly impossible to get any help. Trying to make people look bad
> and yourself good only serves to expose you as the jerk you clearly
> are.

Bite me. I've been here far too long to care how I look to random newbs. And,
fwiw, it's almost certain that a majority of regulars here would agree it's people
like you who make it nearly impossible for, well, people like you to get any help
here. If you can't describe the problem, give it up.

> "Doesn't work" = hSearch gets value of -1 no matter what I do.

What's Err.LastDllError report?

> Prepending the \\?\ doesn't change anything.

There are *fundamental* differences in calling A/W functions from VB. As I stated,
you need to have a grasp on how pointers are passed to external libraries.

> What I was told that my
> code that works with the FindFirstFileA/FindNextFileA would work by
> switching to the W implementation of these functions. I'm finding
> that this is not the case.

Wrong. That is the case. But it's like switching to diesel to improve your milage.
There's "a bit more to it" than just that.

> I read somewhere that you need to pass the parameters to the W
> implementations as UTF-16 strings, but I have yet to have any luck
> with that either. The UTF-16 converter I found was returning null
> strings. I tried using MultiByteToWideChar to generate a UTF-8, but I
> don't think that's really doing much. The handler still receives the
> -1 value.

VB stores all strings as Unicode internally. How you pass them to external
libraries will determine what they recieve. That's *why* I asked you how you were
doing that. In particular, for your declares (function and structure) and the
actual call. If you can't provide those, we're just pounding sand here. <-- last
time I'm nice about that.

> I know this has to be possible, but perhaps not from VBA?

Of course it is.

> If I can get this working in vb6, that'd do fine, too.

From this perspective, they are functionally identical languages.

> I'm just restricted
> from using .Net in my department. Not my choice, just the way
> "business" decisions are made sometimes.

It's a good decision. Trust me. :-)

Btw, I'm curious why you entirely ignored my initial suggestion. Given your
description of the actual problem, it still seems to me like you're working far
harder than needed to find a solution to a problem you don't really have.
--
.NET: It's About Trust!
http://vfred.mvps.org



> On Jul 1, 1:20 pm, "Karl E. Peterson" <k...@mvps.org> wrote:
>> krazymike wrote:
>> > Ok, back to the original topic.
>>
>> > I used FindFirstFileA and FindNextFileA and was able to access a path
>> > of 306 characters. Now, I need to cover the UNICODE characters which
>> > may be in the file names. We get stuff from macs and linux machines
>> > from time to time. As far as I understand, I should be able to change
>> > the A to a W to use the unicode version.
>>
>> Right.
>>
>> > That doesn't work.
>>
>> Huh? You're a *developer* and you post a *user* error report?
>>
>> > prepended the "\\?\" to the path, and had no luck. I'm wondering if I
>> > need some language packs installed to use unicode at all.
>>
>> > Any thoughts?
>>
>> Yeah. But I'll spare you most of them.
>>
>> You need to understand Unimess, first. The way VB mangles the Unicode strings it
>> stores internally, when passing them externally, and vice-versa. To get Unicode
>> in/out of VB, you need to work directly with pointers. How are you declaring the
>> API(s) and their related structures? How are you filling the structures? How are
>> you reading what's returned?
>>
>> "Doesn't work" doesn't even begin to provide the requisite clues.
>> --
>> .NET: It's About Trust!
>> http://vfred.mvps.org

Karl
Tue Jul 01 15:57:08 CDT 2008

krazymike wrote:
> Prepending the \\?\ doesn't change anything. What I was told that my
> code that works with the FindFirstFileA/FindNextFileA would work by
> switching to the W implementation of these functions. I'm finding
> that this is not the case.

Further reading:

Naming a File (Windows)
http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx

Specifically, the "Maximum Path Length" section which covers specifying Unicode and
UNC paths. I'm not sure, given what information you've provided, whether UNC paths
may also be part of what needs to be in consideration here?
--
.NET: It's About Trust!
http://vfred.mvps.org

Howard
Wed Jul 02 04:01:03 CDT 2008

"krazymike" <krazymike@gmail.com> wrote in message
news:16d0bd7c-9e36-4614-8b53-766f7f1e26f6@l64g2000hse.googlegroups.com...
Ok, back to the original topic.

I used FindFirstFileA and FindNextFileA and was able to access a path
of 306 characters. Now, I need to cover the UNICODE characters which
may be in the file names. We get stuff from macs and linux machines
from time to time. As far as I understand, I should be able to change
the A to a W to use the unicode version. That doesn't work. I
prepended the "\\?\" to the path, and had no luck. I'm wondering if I
need some language packs installed to use unicode at all.

Any thoughts?

You have to do more than just change the A to a W.
E.g., In the Declare, for each String Type, change the type to Long, and
pass the string using StrPtr.

I hope that others will help further.
I'm having a serious dental problem and need to find a good oral surgeon
today.

Oh well, getting info is sometines like pulling teet ...!

expvb
Wed Jul 02 07:36:37 CDT 2008

"krazymike" <krazymike@gmail.com> wrote in message
news:fd7bc33f-f06f-4107-84d0-d73ac6f14c99@t54g2000hsg.googlegroups.com...
> Prepending the \\?\ doesn't change anything. What I was told that my
> code that works with the FindFirstFileA/FindNextFileA would work by
> switching to the W implementation of these functions. I'm finding
> that this is not the case.


Post your declaration for the function and how you are calling it. You may
be still using the A version especially if you didn't edit the "Alias" part.
Also, you have to use StrPtr() when using the W version.

krazymike
Wed Jul 02 10:38:13 CDT 2008

Alright, let's start over. I'm sorry I got everyone upset. I was
pretty fed up with my code not working, and my boss breathing down my
neck. This is not actually the last state of my code, but I was so
fed up that I didn't save the changes I had made since it had gotten
pretty ugly-looking.

Before I call FindFilesAPI, I test if the path is UNC or not, and set
the "\\?\" or "\\?\UNC\" accordingly. I also drop the double "\\"
before the UNC path so it's "\\?\UNC\server\share". I can't think
of what else to include here.

Oh, we can't necessarily map closer to the data because this database
gets fed into a document review system from a different machine, and
the address has to be universal. Both for the loading into the review
system, and for while the attorneys actually use the review system.
We're working on a solution to flatten the file structure, but we're
still in the approval process. Don't you just love bureaucracy?

===DECLARES===

Private Declare Function FindFirstFile Lib "kernel32" Alias
"FindFirstFileW" (ByVal lpFileName As String, _
lpFindFileData As WIN32_FIND_DATAW) As Long
Private Declare Function FindNextFile Lib "kernel32" Alias
"FindNextFileW" (ByVal hFindFile As Long, _
lpFindFileData As WIN32_FIND_DATAW) As Long
Private Declare Function GetFileAttributes Lib "kernel32" Alias
"GetFileAttributesA" (ByVal lpFileName As String) As Long
Private Declare Function FindClose Lib "kernel32" (ByVal hFindFile As
Long) As Long

Const MAX_PATH = 260
Const MAXDWORD = &HFFFF
Const INVALID_HANDLE_VALUE = -1
Const FILE_ATTRIBUTE_ARCHIVE = &H20
Const FILE_ATTRIBUTE_DIRECTORY = &H10
Const FILE_ATTRIBUTE_HIDDEN = &H2
Const FILE_ATTRIBUTE_NORMAL = &H80
Const FILE_ATTRIBUTE_READONLY = &H1
Const FILE_ATTRIBUTE_SYSTEM = &H4
Const FILE_ATTRIBUTE_TEMPORARY = &H100

Private Type FILETIME
dwLowDateTime As Long
dwHighDateTime As Long
End Type

Private Type WIN32_FIND_DATAW
dwFileAttributes As Long
ftCreationTime As FILETIME
ftLastAccessTime As FILETIME
ftLastWriteTime As FILETIME
nFileSizeHigh As Long
nFileSizeLow As Long
dwReserved0 As Long
dwReserved1 As Long
cFileName As String * MAX_PATH
cAlternateFileName As String * 14
End Type

===Call===

Function FindFilesAPI(ByVal path As String)
Dim FileName As String ' Walking filename variable...
Dim i As Integer ' For-loop counter...
Dim hSearch As Long ' Search Handle
Dim WFD As WIN32_FIND_DATAW
Dim Cont As Integer
If Right(path, 1) <> "\" Then path = path & "\"
Cont = True
hSearch = FindFirstFile(path & "*.*" & vbNullChar, WFD)
If hSearch <> INVALID_HANDLE_VALUE Then
. . . rest of code.

Mike
Wed Jul 02 13:06:04 CDT 2008

"krazymike" <krazymike@gmail.com> wrote in message
news:8791fea7-87b3-4a86-97b6-95a651a69571@j22g2000hsf.googlegroups.com...

> Before I call FindFilesAPI, I test if the path is UNC or not, and set
> the "\\?\" or "\\?\UNC\" accordingly. I also drop the double "\\"
> before the UNC path so it's "\\?\UNC\server\share". I can't think
> of what else to include here.
> Private Declare Function FindFirstFile Lib "kernel32" Alias
> "FindFirstFileW" (ByVal lpFileName As String, _
> lpFindFileData As WIN32_FIND_DATAW) As Long

VB6 stores all strings internally using two bytes per character and when you
pass a VB String to an API function then VB makes a "one byte per character"
copy of the "2 bytes per character VB String" and passes that instead. The
opposite happens when a String is returned. I never use "W" versions of the
API functions myself, so I'm well out of my depth here, but I think that VB
still behaves in the same way when you use the "W" versions of the function
as well. If that is the case, which I think it is, then to pass the "two
byte per character String" that the above function is expecting you would
need to change the declaration so as to specify lpFileName as Long (instead
of lpFileName as String) and then pass the VB string pointer (as a Long) to
the function.

Mike

krazymike
Wed Jul 02 13:50:09 CDT 2008

Awesome!! It works, save one issue. The filenames alternate chars
with a white square (which I can only see in debug mode). Also, if I
just let the code fly, Access crashes. I have to put in several
breakpoints to slow it down for it to work.

Any ideas?

On Jul 2, 1:06=A0pm, "Mike Williams" <mi...@whiskyandCoke.com> wrote:
> "krazymike" <krazym...@gmail.com> wrote in message
>
> news:8791fea7-87b3-4a86-97b6-95a651a69571@j22g2000hsf.googlegroups.com...
>
> > Before I call FindFilesAPI, I test if the path is UNC or not, and set
> > the "\\?\" or "\\?\UNC\" accordingly. =A0I also drop the double "\\"
> > before the UNC path so it's "\\?\UNC\server\share". =A0 =A0I can't think=

> > of what else to include here.
> > Private Declare Function FindFirstFile Lib "kernel32" Alias
> > "FindFirstFileW" (ByVal lpFileName As String, _
> > lpFindFileData As WIN32_FIND_DATAW) As Long
>
> VB6 stores all strings internally using two bytes per character and when y=
ou
> pass a VB String to an API function then VB makes a "one byte per characte=
r"
> copy of the "2 bytes per character VB String" and passes that instead. The=

> opposite happens when a String is returned. I never use "W" versions of th=
e
> API functions myself, so I'm well out of my depth here, but I think that V=
B
> still behaves in the same way when you use the "W" versions of the functio=
n
> as well. If that is the case, which I think it is, then to pass the "two
> byte per character String" that the above function is expecting you would
> need to change the declaration so as to specify lpFileName as Long (instea=
d
> of lpFileName as String) and then pass the VB string pointer (as a Long) t=
o
> the function.
>
> Mike

Karl
Wed Jul 02 15:51:53 CDT 2008

krazymike wrote:
> Alright, let's start over. I'm sorry I got everyone upset. I was
> pretty fed up with my code not working, and my boss breathing down my
> neck.

Been there. No problem.

> This is not actually the last state of my code, but I was so
> fed up that I didn't save the changes I had made since it had gotten
> pretty ugly-looking.
>
> Before I call FindFilesAPI, I test if the path is UNC or not, and set
> the "\\?\" or "\\?\UNC\" accordingly. I also drop the double "\\"
> before the UNC path so it's "\\?\UNC\server\share". I can't think
> of what else to include here.

That looks like a good start.

> Oh, we can't necessarily map closer to the data because this database
> gets fed into a document review system from a different machine, and
> the address has to be universal. Both for the loading into the review
> system, and for while the attorneys actually use the review system.
> We're working on a solution to flatten the file structure, but we're
> still in the approval process. Don't you just love bureaucracy?

Bummer, yeah.

> ===DECLARES===
>
> Private Declare Function FindFirstFile Lib "kernel32" Alias
> "FindFirstFileW" (ByVal lpFileName As String, _
> lpFindFileData As WIN32_FIND_DATAW) As Long

Change that to (indented to highlight wordwrap):

Private Declare Function FindFirstFile Lib "kernel32" Alias "FindFirstFileW"
(ByVal lpFileName As Long, lpFindFileData As WIN32_FIND_DATAW) As Long

> Private Declare Function FindNextFile Lib "kernel32" Alias
> "FindNextFileW" (ByVal hFindFile As Long, _
> lpFindFileData As WIN32_FIND_DATAW) As Long

Fine.

> Private Declare Function GetFileAttributes Lib "kernel32" Alias
> "GetFileAttributesA" (ByVal lpFileName As String) As Long

Wouldn't you want to use the same filename? If so, ...

Private Declare Function GetFileAttributes Lib "kernel32" Alias
"GetFileAttributesW" (ByVal lpFileName As Long) As Long

> Private Declare Function FindClose Lib "kernel32" (ByVal hFindFile As
> Long) As Long
>
> Const MAX_PATH = 260
> Const MAXDWORD = &HFFFF
> Const INVALID_HANDLE_VALUE = -1
> Const FILE_ATTRIBUTE_ARCHIVE = &H20
> Const FILE_ATTRIBUTE_DIRECTORY = &H10
> Const FILE_ATTRIBUTE_HIDDEN = &H2
> Const FILE_ATTRIBUTE_NORMAL = &H80
> Const FILE_ATTRIBUTE_READONLY = &H1
> Const FILE_ATTRIBUTE_SYSTEM = &H4
> Const FILE_ATTRIBUTE_TEMPORARY = &H100
>
> Private Type FILETIME
> dwLowDateTime As Long
> dwHighDateTime As Long
> End Type
>
> Private Type WIN32_FIND_DATAW
> dwFileAttributes As Long
> ftCreationTime As FILETIME
> ftLastAccessTime As FILETIME
> ftLastWriteTime As FILETIME
> nFileSizeHigh As Long
> nFileSizeLow As Long
> dwReserved0 As Long
> dwReserved1 As Long
> cFileName As String * MAX_PATH
> cAlternateFileName As String * 14
> End Type

This one I'm not entirely sure about, and will actually need to play with. Off the
top of