Long paths
in [VbScript]
|
Prev: Left function is EXECQUERY
Next: Windows 2000 WMI issue
From: krazymike on 30 Jun 2008 12:53 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
From: Pegasus (MVP) on 30 Jun 2008 13:11 "krazymike" <krazymike(a)gmail.com> wrote in message news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84(a)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.
From: krazymike on 30 Jun 2008 13:21 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....(a)fly.com.oz> wrote: > "krazymike" <krazym...(a)gmail.com> wrote in message > > news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84(a)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.
From: Pegasus (MVP) on 30 Jun 2008 14:07 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(a)gmail.com> wrote in message news:f7416f09-1445-4aac-a5dd-8d6727516965(a)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....(a)fly.com.oz> wrote: > "krazymike" <krazym...(a)gmail.com> wrote in message > > news:f93ff032-f3e2-4aa8-affa-6f34f47d7c84(a)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.
From: Howard Kaikow on 30 Jun 2008 14:59
You need to use the Unicode version of API calls. Start by looking at the CreateFileW, the Unicode version of CreateFile. |