• Please review our updated Terms and Rules here

PC "Tweeners"

I routinely use Win98SE on FAT32 volumes with DOS LFN. I get long names. even in non-GUI (Boot to MS-DOS) mode as long as I use Int 21h AX=71xxh to make my calls per spec. There' also a long-to-short API (7160h, IIRC). At any rate Ralf Brown's list has details.
 
The Lan Manager client for DOS would automatically do name mangling and turn long file names into 8.3 names. I believe some of the other DOS networking clients could do the same if attached to a long file name capable server.

I seem to remember that several FTP clients had options to automatically create 8.3 names to replace the longer names.
 
Chuck(G) said:
I routinely use Win98SE on FAT32 volumes with DOS LFN. I get long names. even in non-GUI (Boot to MS-DOS) mode as long as I use Int 21h AX=71xxh to make my calls per spec. There' also a long-to-short API (7160h, IIRC). At any rate Ralf Brown's list has details.
Click to expand...

Does that work if you boot Win 98 from a floppy?

Either way, Win 9x DOS is the exception to the rule. No other DOS has LFN support.
 
Trixter said:
UMB? Did you mean SMB?

When one of my endpoints is a system not capable of running Windows, I've found there is no easier or faster solution than mTCP. Fits on a floppy, and I boot right into the FTP server, then a nice FTP GUI client like FileZilla facilitates "drag'n'drop" between the two systems.
Click to expand...

Had no idea that solution existed. Thanks for the tip. I'll check it out.

Dealing with DOS 8.3 name restrictions: we used to use a little utility called RENAMEWIZ. Link here

-CH-
 
I think some of you may be missing something here.

When you use FTP with mTCP to transfer files from a Windows machine to a DOS machine the FTP program will not be able to transfer those files that have file names that do not conform to the 8.3 format. It will produce error messages, e.g., 'Bad Path or Filename' and 'Critical File Transfer Error' in the log.

Examples:

File1234.zip will transfer but File12345.zip will not.

File1234.htm will transfer but File1234.html will not.

So, if you've got a group of files that contains both files that do and don't conform to the DOS 8.3 convention you're outta luck because you're gonna end up with a mixed bag on the receiving (DOS) end since none of the non 8.3 files will transfer successfully. In actuality you've created more work for yourself since now you've got to *sort* through the original files to remove the ones that don't have 8.3 filenames and transfer them in some other manner.

Why bother with the FTP at all if you've got to do triple the work in the end and will still need to use some other method to get the original job done? This is why I use the DOS-USB method where you copy all the files you want to transfer to a flash drive and then copy all of them to your DOS tweener and let DOS sort out (munge) the long filenames to something with a tilde that it can deal with, i.e., File12~1.zip when it encounters File12345.zip on the transfer list.
 
clh333 said:
Dealing with DOS 8.3 name restrictions: we used to use a little utility called RENAMEWIZ. Link here
Click to expand...
I don't see how that doesn't create more work for you:

1) You rename the renegade files to some 8.3 names.

2) You transfer them to your DOS tweener (via FTP).

3) You're left with a group of files with 8.3 names on your Windows machine where 8.3 names are long passe'. So you need to rename them back to their original names.

If you use the USB-DOS method they automatically get renamed(munged) as soon as they hit the DOS environment and the original files on the Windows machine don't need to be re-renamed back to what they originally were. :)
 
Why use FTP? Because it eliminates the need for the 'tweener' system entirely!

You are complaining that FTP can't deal with the long filenames. (It's not an FTP problem, it's DOS.) You don't want to rename files before copying but really with that entire other computer and OS that is exactly what you are doing.

I use my 'tweeners' for things my older machines can't do - make boot diskettes or do media conversions when there is no networking available. If there is networking available the tweener is not needed. It sounds like you use it to get the automatic file renaming that vfat supports. I'm not sure if that is worth the effort when you probably want names that make more sense on the DOS side.
 
mbbrutman said:
You are complaining that FTP can't deal with the long filenames....

I use my 'tweeners' for things my older machines can't do - make boot diskettes or do media conversions when there is no networking available. If there is networking available the tweener is not needed.
Click to expand...
Not always... here's some recent examples of files I couldn't get transferred via FTP:

1) MemTest86 Because the filename is MemTest86+-V5.01.floppy.zip. :)

2) Microsoft Space Simulator, because I had it stored in a ZIP named Microsoft-Space-Simulator.zip

You see, I also use my tweener for testing and running DOS software of all types so there's a bunch of utility programs on it as well as some games I haven't looked at in a while.

Different strokes for different folks and different needs. No one solution fits all and this is a primary example.

There are enough occasions that arise where I am just stymied by FTP's inability to do what I need to do with regard to DOS' 8.3 convention. So I've adopted the USB-DOS method which works for every file, every time. You know, if it saves a little wear & tear on my brain I'm all for it. :)
 
Copies a remote file to the local computer using the current file transfer type. See also mget, which can copy multiple files.

Syntax: get remote-file [local-file]

Parameter(s):
remote-file
Specifies the remote file to copy.

local-file
Specifies the name to use on the local computer. If not specified, the file is given the remote-file name.
Click to expand...

I still don't see the problem. If you've fooled with Unix/Linux at all, the confusion in file names is present even without ftp; viz, "myfile.dat" is a different file than "MyFile.dat". Ftp basically has an implicit rename function, so you can call the local version whatever you want.
 
I try not to split hairs, but in this case we need to be precise. Just to recap:

  • FAT filesystems (FAT12, FAT16, FAT32) do not support long filenames. Long filenames are hacked on by using hidden directory entries. You need an OS or an extension that supports them natively to use them. Otherwise, you get standard 8.3 filenames.
  • DOS 6.x and below do not support LFNs without a third party driver.

Your USB stick has long filenames on it because you start with an OS that does the hidden entry trickery to add them to the base FAT filesystem. When you move the USB stick to an older system without LFN support, you see the original FAT directory entries which are in the 8.3 format. Your older system works happily with the 8.3 files. It knows nothing of the hidden entries, and does nothing to maintain them.

You are depending on DOS to ignore the hidden entries that store the LFN information. This becomes problematic if you delete and create a file with the same name. Renaming might be broken too. It's a very brittle system.

You are not 'unable' to transfer files using FTP. FTP is fine. The underlying problem is that the OS you are transferring to requires the 8.3 filename format with very specific characters and rules. When you use the USB device and move it between systems, the other OS is effectively doing the rename/long filename mapping for you, so you get to work with those joyous MICROS~1.BAT files. So really all we have is just a matter of where the renaming is being done. With your 'tweener' the OS on that machine is doing it. With FTP you have to do it yourself.

I think it's more correct to say that you are sharing a filesystem between the two machines using USB. Contrast this to copying the file from the USB device onto the local hard drive; you'll lose the long name information when you do that.

Sharing the filesystem is more convenient because you do preserve the long names. But woe unto you if you do something stupid, like run a directory name sorter. And I have no idea what Chkdsk does if it sees an LFN entry in the FAT. There is a lot of potential for unintended side-effects when you move the filesystem to a lesser OS.

As for FTP, it will move whatever you want just fine, and even let you rename it on the same command. It's not an FTP problem - it's a DOS problem.
 
mbbrutman said:
As for FTP, it will move whatever you want just fine, and even let you rename it on the same command.
Click to expand...
Once again, after doing that you have to un-rename said files back to what they were originally which is a second additional process. Where's all the automation? :)
 
Stone said:
Once again, after doing that you have to un-rename said files back to what they were originally which is a second additional process. Where's all the automation? :)
Click to expand...

Get a better FTP client. Attachmate's client included such automated rename features.
 
Stone said:
Once again, after doing that you have to un-rename said files back to what they were originally which is a second additional process. Where's all the automation? :)
Click to expand...

I don't understand, exactly. One of the reasons for renaming to begin with is that the local system doesn't support the original (remote) file name. So you won't get the original named file on your local system anyway.
 
Chuck(G) said:
I don't understand, exactly. One of the reasons for renaming to begin with is that the local system doesn't support the original (remote) file name. So you won't get the original named file on your local system anyway.
Click to expand...
Maybe I don't understand. When you use the FTP client to rename the file it does so on the Windows system before transferring the file to the DOS system. So you end up with the renamed file(s) on both systems, hence the need to unrename the file(s) on the Windows system.
 
There is an FTP rename command. But the renaming we are talking about is different.

Most FTP clients lets you specify a filename to fetch from the server, and an optional filename to use when writing it on your local system. The server side name is untouched; you just simply receive the file with a different name that is suitable for your local system.

For example, get <server_filename> [<local_filename>] is the syntax most clients use, where <local_filename> is optional.
 
Sure. But the mTCP FTP client certainly does, and that's kind of where this thread of the conversation started from, right? Unless you are running FileZilla on a DOS system. ;-0

Most command line FTP clients support the remote-name and local-name syntax for both gets and puts.
 
Yes Chuck ... we are both aligned on the side of goodness. But Stone wasn't getting it. If I had a nickel for every time I thought 'I just said that ...'

I suspect Stone didn't know about that handy little difference between remote and local filenames. After looking at the way that LFNs are implemented I'm totally horrified. For read-only purposes it is safe but it seems really fragile otherwise. The mTCP HTTP server completely sidesteps the LFN problem on pure DOS; it lets you serve paths with long filenames by using its own mapping, kept in the equivalent of a .htaccess file. In retrospect I'm glad I did it this way, but obviously its not portable.
 
You must log in or register to reply here.
Back
Top