Hi Bret,
Thanks for such an informative reply.
I actually suspect you may be correct about the combination of file names.
I requested that the person commissioned to gather and zip the information
do it a second time.
The new .zip archive is..about twice as large as the first one. as in from
about half a gig to almost a full one, with these all being text files.
I suspect that either they did not get everything the first time, or their
correcting special characters in the file names, something they told me
ended up being needful, produced a zip file with all the goods.
I suspect? it will be best to create the entire archive again, rather than
try and let pkunzip fix the first one with this new zip archive.
If I wish to remove everything, would this be the deltree utility? its
been a long long time, and I am using ms dos 7.1
Thanks again,
Kare
On Tue, 28 Jun 2016, Bret Johnson wrote:
> I'm a little late responding to this. I haven't seen these particular things
> discussed yet, and I think they need to be.
>
> Regarding directories, there is the "width" (the number of
> files/subdirectories in a {sub}directory) and the "height" (the number of
> levels of subdirectories underneath the root). The root directory does have
> a width limit which is defined when the drive is formatted (usually 128, 256,
> or 512). The root directory is the only one with a width limit -- there is
> no limit to the number of files/subdirectories in a subdirectory (other than
> the fact that all of the entries must be uniquely named). Also, as a side
> note, early versions of FAT did not even allow subdirectories.
>
> While technically there is no limit to the depth, the entire name of a file,
> including the drive letter, colon, backslashes, and dots, cannot be longer
> than 64 characters total when using short (8.3) names. DOS uses 64-byte
> buffers to transfer names back and forth internally as it is manipulating the
> files and directories, and that is a hard limit.
>
> So, if your directory names are only one or two characters each, you can go
> several levels deep. If they're all 8 letters (or even longer if you use 8.3
> directory names), you can only go a few levels deep. Also not that the
> 64-character limit applies AFTER the file names are expanded (e.g., if you
> normally use "." and "..", or leave out the drive letter, use SUBST drives,
> use environment variables, etc.).
>
> When using Long File Names, there is also a limit, but it is much longer --
> 260 characters.
>
> ---
>
> Regarding your particular problem, I suspect it is related to the
> relationship between short and long file names, and the naming
> inconsistencies that occur between different systems as directories and files
> are manipulated. I will give a specific example.
>
> Many years ago (when Windows 95 was still en vogue), the IT department at a
> company I worked for sent out a batch file that everybody was supposed to run
> on their computer to fix some kind of problem (I don't remember exactly what
> it was supposed to fix, and it is irrelevant to the point, anyway). In
> Windows there is a "Program Files" directory, which is normally PROGRA~1 when
> using short file names. In the batch file the IT department sent out, it
> referenced the directory as PROGRA~1 wither bothering to check if PROGRA~1
> even existed. On my computer, it didn't -- I had manipulated my directory
> structure enough that my short name for "Program Files" was PROGRA~2 instead
> of PROGRA~1. I called the IT department and told them what I found, and they
> basically told me it was my fault and they weren't going to change their
> batch file.
>
> It's possible that your particular problems are related to something like
> that -- the short file names of one computer conflict with or somehow
> "confuse" the other computer. I don't think you said which DOS LFN program
> you were using (there are several of them and they all have their own
> quirks). It's possible that one of the programs (PKZIP/PKUNZIP, the LFN
> program, the DOS kernel) is buggy, or that some combination of the programs
> is acting weird, particularly if the short file names are not consistent on
> the different computers. When you're mixing long and short file names
> together you need to be very careful -- things don't always work quite like
> you would expect.
>
> Long File Names are nice, but the way MS actually implemented them in FAT
> was, in my opinion, a horrible design.
> ____________________________________________________________
> Fivebreak.com
> 40 Years of the Same Photo Together, But The Last One is Incredible
> http://thirdpartyoffers.juno.com/TGL3141/5772286c618f6286c1e97st02vuc
>
> ------------------------------------------------------------------------------
> Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
> Francisco, CA to explore cutting-edge tech and listen to tech luminaries
> present their vision of the future. This family event has something for
> everyone, including kids. Get more information and register today.
> http://sdm.link/attshape
> _______________________________________________
> Freedos-user mailing list
> Freedos-user@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/freedos-user
>
>
------------------------------------------------------------------------------
Attend Shape: An AT&T Tech Expo July 15-16. Meet us at AT&T Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
_______________________________________________
Freedos-user mailing list
Freedos-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-user
