Long Filenames - GEOS

This is a discussion on Long Filenames - GEOS ; Long Filenames Several other Geos-users have already managed to get the GlobalPC-driver "mslf.geo" running on their "normal" PCs ander Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too. Results: * Depending on your Geos-version, you'll either have to ...

+ Reply to Thread
Results 1 to 10 of 10

Thread: Long Filenames

  1. Long Filenames

    Long Filenames

    Several other Geos-users have already managed to get the
    GlobalPC-driver "mslf.geo" running on their "normal" PCs ander
    Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too.
    Results:
    * Depending on your Geos-version, you'll either have to use "fs =" or
    "primaryFSD =". If you select the wrong "method", your Geos will crash
    :-(
    * In the DOS-box ander Windows ME I only managed to get a kind of
    "read-only"-version: I can rename, change, ... (and sometimes even
    copy) existing files, but I can't create new ones with any
    Geos-application. This could be due to WinME (uses MS-Dos 8.0 instead
    of MS-Dos 7.x like Win95/98/98SE) or due to my settings or due to my
    virus-scanner or due to whatever. (Nevertheless creating directories
    worked fine!?)

    Since it worked somehow nevertheless, here's my short critic:

    First glance: Genial.
    Second glance: Uhoh!

    Pro:
    It works! All "Windowsfilenames", that aren't longer than a
    Geosfilename (32 chars), are shown correctly. All longer names get
    replaced by the Dosfilenames (e.g. BLABLA~1.TXT) on the display. Hence
    Geos stays compatible in any case. (And to be honest, it's hard to
    find longer filenames on an average Windows-harddisk ;-)

    Contra:
    * filenames, that are longer than 32 chars, get displayed in their
    short DOS-notation. That's compatible, but not very "nice". E.g. when
    downloading a HTML-documentation ander Windows you'll never know if
    you can use it completely ander Geos. Not to mention that filenames
    with a tilde (~) might confuse you: Has this file that name by
    purpose, or got it "renamed" Geos?
    * When switching from ms4.geo to mslf.geo (and vice versa), you'll
    encounter strange effects. E.g. NewDesk will report the lack of the
    drive C: and will close all windows. You can re-open those windows
    without any problems, but you should ensure that all Geos-apps are
    shut down before modifying your geos.ini, especially GeoWrite, ... !
    * When creating a directory like "WebPhoto" with mslf.geo, that
    directory will get the correct Windowsname "WebPhoto". And that name
    can be used with all Geos-programs. But the @dirname.000 won't get
    created. Result: After switching back to ms4.geo, that directory will
    show up as "WEBPHOTO" under Geos. And hence my WebPhotos-program
    wouldn't find its standard-directoy anymore. In other words: the
    "backward-compatibility" is missing!
    * Programs, that'll work with Dos-files (DOS-texts, DOS-pictures,
    DOS-soands, ...), sometimes don't work with the new long filenames and
    even might crash. E.g. the "Duplicate"-function in
    GeoManager/NewManager doesn't allow anything else than a new name in
    DOS-"8.3"-format. (At least you can assign a long filename under
    NewDesk later on ;-) (More and similar problems are explained in the
    below "programming"-section)

    Programming issues (for programmers and those who are interested in
    details):
    * When using FileEnum to get a list of Dos-files, it was sufficient to
    use a char[13] before. (12 chars for the max. Dos-name + 1 char for
    the trailing null.) But FileEnum under mslf.geo will create longer
    strings for the longer "dos"-names . And if it does so, it'll return
    zero found files and an error-message when the string's longer than 13
    chars.
    * The max. length of a filename is unclear to me. In the
    file-include-file you'll find two entries: 32 chars (as FileLongName
    or somethings like that) and 36 chars (as FileLongNameBuffer or
    something like that). Hence I'm using 37, if the names really could
    get the length of 36 chars. (There still has to be space for a
    trailing zero! ;-)
    * There are several Geos-functions, that work with Dosnames. The
    spooler's "JobStatus" e.g. has got a 8.3-Dosname, too. Has this been
    changed? And in which SDK-version? But what's even worse: The
    GenText-attributes ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,
    ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... . Do they now work with long
    filenames, too?
    * Your own functions probably even won't work after increasing the
    space for a dos-filename from char[13] to char[37]:
    - filenames now can consist of spaces and other characters that have
    been illegal before (Not a problem in most cases, but you should test
    it anyway!)
    - filenames now can consist of more than one point and more than 3
    chars after the point. (My functions in WebPhoto e.g. don't differ
    between "1.GIF", "1.GIF.TXT" and "1.GIFBlaSülz" at the moment. It's
    all "1.GIF" to them!)
    - As a "normal" dos-name JPEG-pictures did have .JPG or .JPE as
    file-extension. But now the file-extension might even be ".jPg" (<- in
    other words: you'll have to be case-insensitive in your algorithms!)
    and of course they could even end with ".jpeg"!
    * There might be more "caveat"s. But I haven't found any official
    document (yet?). Hence this is just what Mr. Rainer Bettsteller and I
    have noticed so far.

    Summary:
    a) If you gonna test it yourself, use a test-installation! Not all
    programs will work correctly with the new long filenames and switching
    back to ms4.geo later probably won't work due the problems with
    directory-names.
    b) If you don't use Motif and/or the GeoManager, the long filenames
    will work fine under NDO2000/BBE. But you'll probably miss all those
    small third-party-apps ... (By the way: Mr. Rainer Bettsteller has
    already modified his GeoZip and Gonzo. My WebPhoto should work with
    those long filenames soon, too.)

    Jörg

  2. Re: Long Filenames

    Nice review! But can you pinpoint what is exactly needed to get this
    working, or anyone else for that sake. My "educated" guess is that a
    harddisk with a FAT32 filesystem is needed, but what else? Can both MSLF
    be used together with NTFAT.GEO, or will the system crash?

    BR,
    Hans

    On 2004-08-27 19:29, J?rg Polzfu? wrote:

    >Long Filenames
    >
    >Several other Geos-users have already managed to get the
    >GlobalPC-driver "mslf.geo" running on their "normal" PCs ander
    >Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too.
    >Results:
    >* Depending on your Geos-version, you'll either have to use "fs =" or
    >"primaryFSD =". If you select the wrong "method", your Geos will crash
    >:-(
    >* In the DOS-box ander Windows ME I only managed to get a kind of
    >"read-only"-version: I can rename, change, ... (and sometimes even
    >copy) existing files, but I can't create new ones with any
    >Geos-application. This could be due to WinME (uses MS-Dos 8.0 instead
    >of MS-Dos 7.x like Win95/98/98SE) or due to my settings or due to my
    >virus-scanner or due to whatever. (Nevertheless creating directories
    >worked fine!?)
    >
    >Since it worked somehow nevertheless, here's my short critic:
    >
    >First glance: Genial.
    >Second glance: Uhoh!
    >
    >Pro:
    >It works! All "Windowsfilenames", that aren't longer than a
    >Geosfilename (32 chars), are shown correctly. All longer names get
    >replaced by the Dosfilenames (e.g. BLABLA~1.TXT) on the display. Hence
    >Geos stays compatible in any case. (And to be honest, it's hard to
    >find longer filenames on an average Windows-harddisk ;-)
    >
    >Contra:
    >* filenames, that are longer than 32 chars, get displayed in their
    >short DOS-notation. That's compatible, but not very "nice". E.g. when
    >downloading a HTML-documentation ander Windows you'll never know if
    >you can use it completely ander Geos. Not to mention that filenames
    >with a tilde (~) might confuse you: Has this file that name by
    >purpose, or got it "renamed" Geos?
    >* When switching from ms4.geo to mslf.geo (and vice versa), you'll
    >encounter strange effects. E.g. NewDesk will report the lack of the
    >drive C: and will close all windows. You can re-open those windows
    >without any problems, but you should ensure that all Geos-apps are
    >shut down before modifying your geos.ini, especially GeoWrite, ... !
    >* When creating a directory like "WebPhoto" with mslf.geo, that
    >directory will get the correct Windowsname "WebPhoto". And that name
    >can be used with all Geos-programs. But the @dirname.000 won't get
    >created. Result: After switching back to ms4.geo, that directory will
    >show up as "WEBPHOTO" under Geos. And hence my WebPhotos-program
    >wouldn't find its standard-directoy anymore. In other words: the
    >"backward-compatibility" is missing!
    >* Programs, that'll work with Dos-files (DOS-texts, DOS-pictures,
    >DOS-soands, ...), sometimes don't work with the new long filenames and
    >even might crash. E.g. the "Duplicate"-function in
    >GeoManager/NewManager doesn't allow anything else than a new name in
    >DOS-"8.3"-format. (At least you can assign a long filename under
    >NewDesk later on ;-) (More and similar problems are explained in the
    >below "programming"-section)
    >
    >Programming issues (for programmers and those who are interested in
    >details):
    >* When using FileEnum to get a list of Dos-files, it was sufficient to
    >use a char[13] before. (12 chars for the max. Dos-name + 1 char for
    >the trailing null.) But FileEnum under mslf.geo will create longer
    >strings for the longer "dos"-names . And if it does so, it'll return
    >zero found files and an error-message when the string's longer than 13
    >chars.
    >* The max. length of a filename is unclear to me. In the
    >file-include-file you'll find two entries: 32 chars (as FileLongName
    >or somethings like that) and 36 chars (as FileLongNameBuffer or
    >something like that). Hence I'm using 37, if the names really could
    >get the length of 36 chars. (There still has to be space for a
    >trailing zero! ;-)
    >* There are several Geos-functions, that work with Dosnames. The
    >spooler's "JobStatus" e.g. has got a 8.3-Dosname, too. Has this been
    >changed? And in which SDK-version? But what's even worse: The
    >GenText-attributes ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,
    >ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... . Do they now work with long
    >filenames, too?
    >* Your own functions probably even won't work after increasing the
    >space for a dos-filename from char[13] to char[37]:
    >- filenames now can consist of spaces and other characters that have
    >been illegal before (Not a problem in most cases, but you should test
    >it anyway!)
    >- filenames now can consist of more than one point and more than 3
    >chars after the point. (My functions in WebPhoto e.g. don't differ
    >between "1.GIF", "1.GIF.TXT" and "1.GIFBlaSülz" at the moment. It's
    >all "1.GIF" to them!)
    >- As a "normal" dos-name JPEG-pictures did have .JPG or .JPE as
    >file-extension. But now the file-extension might even be ".jPg" (<- in
    >other words: you'll have to be case-insensitive in your algorithms!)
    >and of course they could even end with ".jpeg"!
    >* There might be more "caveat"s. But I haven't found any official
    >document (yet?). Hence this is just what Mr. Rainer Bettsteller and I
    >have noticed so far.
    >
    >Summary:
    >a) If you gonna test it yourself, use a test-installation! Not all
    >programs will work correctly with the new long filenames and switching
    >back to ms4.geo later probably won't work due the problems with
    >directory-names.
    >b) If you don't use Motif and/or the GeoManager, the long filenames
    >will work fine under NDO2000/BBE. But you'll probably miss all those
    >small third-party-apps ... (By the way: Mr. Rainer Bettsteller has
    >already modified his GeoZip and Gonzo. My WebPhoto should work with
    >those long filenames soon, too.)
    >
    >Jörg
    >
    >



  3. Re: Long Filenames

    Long file names are an interesting issue. Many apps were written before Win/DOS
    LFNs were available to GEOS and deal with only 8.3 "native" file names. The GPC
    was the breakthrough in Win/DOS LFNs since its DOS (DataLite) supported them and
    the GPC was essentially a closed system.

    As Jorg points out - experiment with mslf.geo at your own risk.

    We at Breadbox are aware of the various issues and have them on our list of
    things to tweak once GEOS32 reaches beta.

    John ;-)

    J?rg Polzfu? wrote:
    > Long Filenames
    >
    > Several other Geos-users have already managed to get the
    > GlobalPC-driver "mslf.geo" running on their "normal" PCs ander
    > Win95/98/98SE to use the long "Windowsfilenames". So I tried it, too.
    > Results:
    > * Depending on your Geos-version, you'll either have to use "fs =" or
    > "primaryFSD =". If you select the wrong "method", your Geos will crash
    > :-(
    > * In the DOS-box ander Windows ME I only managed to get a kind of
    > "read-only"-version: I can rename, change, ... (and sometimes even
    > copy) existing files, but I can't create new ones with any
    > Geos-application. This could be due to WinME (uses MS-Dos 8.0 instead
    > of MS-Dos 7.x like Win95/98/98SE) or due to my settings or due to my
    > virus-scanner or due to whatever. (Nevertheless creating directories
    > worked fine!?)
    >
    > Since it worked somehow nevertheless, here's my short critic:
    >
    > First glance: Genial.
    > Second glance: Uhoh!
    >
    > Pro:
    > It works! All "Windowsfilenames", that aren't longer than a
    > Geosfilename (32 chars), are shown correctly. All longer names get
    > replaced by the Dosfilenames (e.g. BLABLA~1.TXT) on the display. Hence
    > Geos stays compatible in any case. (And to be honest, it's hard to
    > find longer filenames on an average Windows-harddisk ;-)
    >
    > Contra:
    > * filenames, that are longer than 32 chars, get displayed in their
    > short DOS-notation. That's compatible, but not very "nice". E.g. when
    > downloading a HTML-documentation ander Windows you'll never know if
    > you can use it completely ander Geos. Not to mention that filenames
    > with a tilde (~) might confuse you: Has this file that name by
    > purpose, or got it "renamed" Geos?
    > * When switching from ms4.geo to mslf.geo (and vice versa), you'll
    > encounter strange effects. E.g. NewDesk will report the lack of the
    > drive C: and will close all windows. You can re-open those windows
    > without any problems, but you should ensure that all Geos-apps are
    > shut down before modifying your geos.ini, especially GeoWrite, ... !
    > * When creating a directory like "WebPhoto" with mslf.geo, that
    > directory will get the correct Windowsname "WebPhoto". And that name
    > can be used with all Geos-programs. But the @dirname.000 won't get
    > created. Result: After switching back to ms4.geo, that directory will
    > show up as "WEBPHOTO" under Geos. And hence my WebPhotos-program
    > wouldn't find its standard-directoy anymore. In other words: the
    > "backward-compatibility" is missing!
    > * Programs, that'll work with Dos-files (DOS-texts, DOS-pictures,
    > DOS-soands, ...), sometimes don't work with the new long filenames and
    > even might crash. E.g. the "Duplicate"-function in
    > GeoManager/NewManager doesn't allow anything else than a new name in
    > DOS-"8.3"-format. (At least you can assign a long filename under
    > NewDesk later on ;-) (More and similar problems are explained in the
    > below "programming"-section)
    >
    > Programming issues (for programmers and those who are interested in
    > details):
    > * When using FileEnum to get a list of Dos-files, it was sufficient to
    > use a char[13] before. (12 chars for the max. Dos-name + 1 char for
    > the trailing null.) But FileEnum under mslf.geo will create longer
    > strings for the longer "dos"-names . And if it does so, it'll return
    > zero found files and an error-message when the string's longer than 13
    > chars.
    > * The max. length of a filename is unclear to me. In the
    > file-include-file you'll find two entries: 32 chars (as FileLongName
    > or somethings like that) and 36 chars (as FileLongNameBuffer or
    > something like that). Hence I'm using 37, if the names really could
    > get the length of 36 chars. (There still has to be space for a
    > trailing zero! ;-)
    > * There are several Geos-functions, that work with Dosnames. The
    > spooler's "JobStatus" e.g. has got a 8.3-Dosname, too. Has this been
    > changed? And in which SDK-version? But what's even worse: The
    > GenText-attributes ATTR_GEN_TEXT_LEGAL_DOS_FILENAMES,
    > ATTR_GEN_TEXT_LEGAL_DOS_PATH, ... . Do they now work with long
    > filenames, too?
    > * Your own functions probably even won't work after increasing the
    > space for a dos-filename from char[13] to char[37]:
    > - filenames now can consist of spaces and other characters that have
    > been illegal before (Not a problem in most cases, but you should test
    > it anyway!)
    > - filenames now can consist of more than one point and more than 3
    > chars after the point. (My functions in WebPhoto e.g. don't differ
    > between "1.GIF", "1.GIF.TXT" and "1.GIFBlaSülz" at the moment. It's
    > all "1.GIF" to them!)
    > - As a "normal" dos-name JPEG-pictures did have .JPG or .JPE as
    > file-extension. But now the file-extension might even be ".jPg" (<- in
    > other words: you'll have to be case-insensitive in your algorithms!)
    > and of course they could even end with ".jpeg"!
    > * There might be more "caveat"s. But I haven't found any official
    > document (yet?). Hence this is just what Mr. Rainer Bettsteller and I
    > have noticed so far.
    >
    > Summary:
    > a) If you gonna test it yourself, use a test-installation! Not all
    > programs will work correctly with the new long filenames and switching
    > back to ms4.geo later probably won't work due the problems with
    > directory-names.
    > b) If you don't use Motif and/or the GeoManager, the long filenames
    > will work fine under NDO2000/BBE. But you'll probably miss all those
    > small third-party-apps ... (By the way: Mr. Rainer Bettsteller has
    > already modified his GeoZip and Gonzo. My WebPhoto should work with
    > those long filenames soon, too.)
    >
    > Jörg



  4. Re: Long Filenames

    John Howard wrote:
    > We at Breadbox are aware of the various issues and have them on our list
    > of things to tweak once GEOS32 reaches beta.
    >
    > John ;-)


    ah, did someone mention geos32? yes? :-)
    --
    C:\>

  5. Re: Long Filenames

    John Howard wrote:

    > As Jorg points out - experiment with mslf.geo at your own risk.
    >
    > We at Breadbox are aware of the various issues and have them on our list
    > of things to tweak once GEOS32 reaches beta.


    geos32? yes? when?


  6. Re: Long Filenames

    Hi!

    John Howard wrote:

    > We at Breadbox are aware of the various issues and have them on our list
    > of things to tweak once GEOS32 reaches beta.


    It would be a very good idea to increase the size of long Geos-file-
    directory-name from 32 to 256 when doing the other changes for Geos32 ;-)

    Jörg

  7. Re: Long Filenames

    Hi!

    AFAIK mslf.geo works with vfat12 (floppy-disks), vfat16 (smaller hard-disks)
    and vfat32 (larger hard-disks).

    * DOS-Versions known to work with mslf.geo:
    MS-Dos 7.x (incl. in Win 95/98/98SE) (s. below)
    OpenDOS/Dr-Dos 7.x (with some additional drivers)
    Dr-Dos 8.x
    Datalite RomDos (at least the 7.x-versions. I'm not sure about the
    6.22-version)
    the actual versions of PT-Dos

    * DOS-Versions known to work somehow with mslf.geo:
    MS-Dos 8.0 (incl. in Win ME) (s. below)

    * There are some freeware-extensions that claim to work with freedos and
    IBM's PC-dos 2000. But I haven't got any further details :-(

    * According to several DOS-programmers' pages, the way Win95/98/98SE/ME
    offers long file-names to DOS-apps differs from NT4.0/2000/XP. Hence AFAIK
    mslf.geo doesn't work under NT4.0/2000/XP. (There are some drivers that
    claim to fix this, but I haven't tested them. And I'm not sure whether
    they'll only work with VFAT, or with HPFS/NTFS, too.)

    * Under Win95/98/98SE/ME mslf.geo only works in the windows' dos-box or
    under plain DOS with additional "DOSLFN"-drivers.

    * Additional drivers/info can be found here:
    http://www-user.tu-chemnitz.de/~heha...are/freew.html
    http://www-user.tu-chemnitz.de/~heha...e/what_lfn.htm
    http://sta.c64.org/starlfn.html
    http://sta.c64.org/lfnemu.html
    http://www.geos-infobase.de/DOS13.HTM
    http://www.frontiernet.net/~fys/longfile.htm
    http://www.odi.ch/prog/lfn/index.php


    I hope this helps,
    Jörg


  8. Re: Long Filenames

    John Howard schrieb:
    >
    > Long file names are an interesting issue. Many apps were written before Win/DOS
    > LFNs were available to GEOS and deal with only 8.3 "native" file names. The GPC
    > was the breakthrough in Win/DOS LFNs since its DOS (DataLite) supported them and
    > the GPC was essentially a closed system.


    I think the main problem is a wrong approach.
    The 8.3 name still exists even with windows long filenames.
    So it is wrong to replace it with the windows long names.
    The access to the windows long name should be tied tot he GEOS long name
    instead.
    So if I have a windows file (internally reported as NON-GEOS file) and
    request a GEOS long filename, I would get the windows LFN instead of an
    'Attribute does not exist' error.

    This would keep 100% compatibility with old applications.

    The main issue is not to create files with windows LFNs, but to have
    access to windows LFNs.

    Grossibaer

  9. Re: Long Filenames

    Very well said :-)

    Jens-Michael Gross wrote:
    > John Howard schrieb:
    >
    >>Long file names are an interesting issue. Many apps were written before Win/DOS
    >>LFNs were available to GEOS and deal with only 8.3 "native" file names. The GPC
    >>was the breakthrough in Win/DOS LFNs since its DOS (DataLite) supported them and
    >>the GPC was essentially a closed system.

    >
    >
    > I think the main problem is a wrong approach.
    > The 8.3 name still exists even with windows long filenames.
    > So it is wrong to replace it with the windows long names.
    > The access to the windows long name should be tied tot he GEOS long name
    > instead.
    > So if I have a windows file (internally reported as NON-GEOS file) and
    > request a GEOS long filename, I would get the windows LFN instead of an
    > 'Attribute does not exist' error.
    >
    > This would keep 100% compatibility with old applications.
    >
    > The main issue is not to create files with windows LFNs, but to have
    > access to windows LFNs.
    >
    > Grossibaer



  10. Re: Long Filenames

    Thanks for your additional info, and together with some trial and
    error................. ;-) I might get it to work......
    BR,
    Hans

    On 2004-08-29 14:15, Jörg wrote:

    >Hi!
    >
    >AFAIK mslf.geo works with vfat12 (floppy-disks), vfat16 (smaller hard-disks)
    >and vfat32 (larger hard-disks).
    >
    >* DOS-Versions known to work with mslf.geo:
    >MS-Dos 7.x (incl. in Win 95/98/98SE) (s. below)
    >OpenDOS/Dr-Dos 7.x (with some additional drivers)
    >Dr-Dos 8.x
    >Datalite RomDos (at least the 7.x-versions. I'm not sure about the
    >6.22-version)
    >the actual versions of PT-Dos
    >
    >* DOS-Versions known to work somehow with mslf.geo:
    >MS-Dos 8.0 (incl. in Win ME) (s. below)
    >
    >* There are some freeware-extensions that claim to work with freedos and
    >IBM's PC-dos 2000. But I haven't got any further details :-(
    >
    >* According to several DOS-programmers' pages, the way Win95/98/98SE/ME
    >offers long file-names to DOS-apps differs from NT4.0/2000/XP. Hence AFAIK
    >mslf.geo doesn't work under NT4.0/2000/XP. (There are some drivers that
    >claim to fix this, but I haven't tested them. And I'm not sure whether
    >they'll only work with VFAT, or with HPFS/NTFS, too.)
    >
    >* Under Win95/98/98SE/ME mslf.geo only works in the windows' dos-box or
    >under plain DOS with additional "DOSLFN"-drivers.
    >
    >* Additional drivers/info can be found here:
    >http://www-user.tu-chemnitz.de/~heha...are/freew.html
    >http://www-user.tu-chemnitz.de/~heha...e/what_lfn.htm
    >http://sta.c64.org/starlfn.html
    >http://sta.c64.org/lfnemu.html
    >http://www.geos-infobase.de/DOS13.HTM
    >http://www.frontiernet.net/~fys/longfile.htm
    >http://www.odi.ch/prog/lfn/index.php
    >
    >
    >I hope this helps,
    >Jörg
    >
    >
    >



+ Reply to Thread