Author |
Message |
krazymik #1 / 25
|
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 |
|
|
MVP #2 / 25
|
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 |
|
|
krazymik #3 / 25
|
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 |
|
|
MVP #4 / 25
|
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 |
|
|
Howard Kaiko #5 / 25
|
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 |
|
|
Ralp #6 / 25
|
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 |
|
|
krazymik #7 / 25
|
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 |
|
|
Klatu #8 / 25
|
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 |
|
|
Mike William #9 / 25
|
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 |
|
|
Albert D. Kalla #10 / 25
|
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 |
|
|
Mike William #11 / 25
|
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 |
|
|
Tom Shelto #12 / 25
|
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 |
|
|
Mike William #13 / 25
|
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 |
|
|
Karl E. Peterso #14 / 25
|
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 |
|
|
Ron Weine #15 / 25
|
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 |
|
|
Page 1 of 2
|
[ 25 post ] |
|
Go to page:
[1]
[2] |
|