Long paths 
Author Message
 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



Sat, 18 Dec 2010 00:53:53 GMT  
 Long paths


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


Sat, 18 Dec 2010 01:11:18 GMT  
 Long paths
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.


Quote:


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



Sat, 18 Dec 2010 01:21:21 GMT  
 Long paths
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.


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.


Quote:


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



Sat, 18 Dec 2010 02:07:30 GMT  
 Long paths
You need to use the Unicode version of API calls.

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



Sat, 18 Dec 2010 02:59:44 GMT  
 Long paths


Quote:
> 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



Sat, 18 Dec 2010 03:06:14 GMT  
 Long paths
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.


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



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




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



Sat, 18 Dec 2010 03:26:22 GMT  
 Long paths
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
Quote:

> 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



Sat, 18 Dec 2010 03:28:07 GMT  
 Long paths

Quote:
> 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



Sat, 18 Dec 2010 03:51:11 GMT  
 Long paths
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



Sat, 18 Dec 2010 04:26:27 GMT  
 Long paths


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



Sat, 18 Dec 2010 05:10:44 GMT  
 Long paths

Quote:


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



Sat, 18 Dec 2010 05:34:29 GMT  
 Long paths

Quote:
> 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



Sat, 18 Dec 2010 05:57:57 GMT  
 Long paths

Quote:

> 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


Sat, 18 Dec 2010 07:57:57 GMT  
 Long paths
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


Quote:
> 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



Sat, 18 Dec 2010 08:13:33 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Long Path Names give Runtime error 76 - Path not found

2. Changing Long Paths to Short Paths in a 16-bit App

3. Problem with OpenDatabase method with long path name

4. Change long path name to short pathname

5. Correct a Long Path

6. really really long path names - phrogg

7. Long path names in a label

8. Long Path Names and 16 Bit

9. Convert Long Path to Short

10. long path name question

11. long path name question

12. FileListBox doesn't support long paths

 

 
Powered by phpBB® Forum Software