I don't either understand why using long file-names and long directory
navigations... such things are said just to AVOID THEM !
As if it well being an easy making if having titles of books or whatever, but
if your stacking up stuff or items, objects you sooner or later run into -
probleeamas, as
Colin Kettenacker wrote:
I could be wrong about this (it's been a while since I've used
fileIO) but I
thought fileIO only had a problem with long file paths in the openFile()
function. With the createFile() function you should be able to
use a normal file path without having to resort to the
Brad Hile [EMAIL PROTECTED] on 12/2/02 5:45 AM wrote:
Colin you're brilliant! (fading memory or not)
*Blushing*
Naaah, I just bumped into the same problem you have.
As to why I would possibly want a path over 126 chars? It's just a case of
better sure than sorry as the app I'm building
Just wondering if someone can add a new perspective to a problem.
I am developing for a win system and using fileio.
Currently fileIO has a problem with paths over 126 chars so I use BuddyAPI's
baShortfilename to truncate the path.
All good so far, but now the problem arises.
The baShortFileName
The baShortFileName only returns a truncated name from a file that already
exists
I did not know that. I thought it would create a short file path even if the
actual file did not exist. I must admit though that I have only used the
function on file paths that did exist.
Therefore I can't
The DOS command path (including file names) is limited to 255 chars, not
sure about internal limits on FileIO.
Short names are generated by the operating system; there is no way to know
ahead of time what it will be (although you could write an algorithm to
guess, based on existing files,
At 16:41 30.11.2002 +0800, Brad Hile wrote:
The baShortFileName only returns a truncated name from a file that already
exists and I'm currently using the create method of the xtra.
Therefore I can't create the file because I can't trucate the path and I
can't truncate the path because I can't
