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

"krazymike" <krazymike@xxxxxx> wrote in message
news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@xxxxxx

> 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.

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....@xxxxxx> wrote:

> "krazymike" <krazym...@xxxxxx> wrote in message
>
> news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@xxxxxx
>
>
>

> > 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.

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@xxxxxx> wrote in message
news:f7416f09-1445-4aac-a5dd-8d6727516965@xxxxxx
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....@xxxxxx> wrote:

> "krazymike" <krazym...@xxxxxx> wrote in message
>
> news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@xxxxxx
>
>
>

> > 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.

You need to use the Unicode version of API calls.

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

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*pm, "Pegasus \(MVP\)" <I....@xxxxxx> 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...@xxxxxx> wrote in message
>
> news:f7416f09-1445-4aac-a5dd-8d6727516965@xxxxxx
> 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....@xxxxxx> wrote:
>

> > "krazymike" <krazym...@xxxxxx> wrote in message

>

> >news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84@xxxxxx

>

> > > 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.

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
>

"krazymike" <krazymike@xxxxxx> wrote in message
news:c4714faa-7b55-46fd-8d17-81968a76e7e4@xxxxxx

> 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

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@xxxxxx

"Albert D. Kallal" <PleaseNOOOsPAMmkallal@xxxxxx> wrote in message
news:%23NRbT%23u2IHA.3544@xxxxxx

> [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