But then it wouldn't be compatible with the LFN that came with Windows9X and is used in the millions of USB devices or the like, nor with the applications that are LFN-aware (unless you'd like to rewrite the DOS LFN API descript.ion-based...
Aitor 2009/4/2 Eric Auer <e.a...@jpberlin.de>: > > Hi! > >>> So why cant we just create a "database/table - file" that allows >>> lookup in a second area, either a file on >>> the hard drive or a separate partition. then based on the >>> file/directory "ID" and store that in the database table completely >>> separate from the FAT if we don't touch fat it should be fine. If we >>> are using a different method and system we are safe. >> >> In reality, though, linux filesystem drivers have been using this >> method of accessing/writing long filenames for years; if Microsoft >> were to go after an operating system, it would be linux first. And as >> Eric pointed out to me, they seem to go more after embedded devices >> that use long filenames on FAT filesystems. So really, I don't think >> there's anything to worry about. > > I think a descript.ion file based driver to support > long file names would be a fine idea indeed :-). > And it would avoid the ugly kludgy way in which MS > stores LFN spread over multiple directory entries. > > Eric > > > ------------------------------------------------------------------------------ > _______________________________________________ > Freedos-user mailing list > Freedos-user@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/freedos-user > ------------------------------------------------------------------------------ _______________________________________________ Freedos-user mailing list Freedos-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-user
