Re: Reply to Airman PD -- Windows Zip folders failures
From: George (anonymous_at_discussions.microsoft.com)
Date: 04/07/04
- Next message: Ken Blake, MVP: "Re: E-mail alert at start-up"
- Previous message: EGR: "Re: configuring a printer"
- In reply to: Airman PD: "Re: Reply to Airman PD -- Windows Zip folders failures"
- Next in thread: Airman PD: "Re: Reply to Airman PD -- Windows Zip folders failures"
- Reply: Airman PD: "Re: Reply to Airman PD -- Windows Zip folders failures"
- Messages sorted by: [ date ] [ thread ]
Date: Wed, 7 Apr 2004 11:34:03 -0700
Thanks, Airman PD.
When you say "rename", do you mean that I should rename the
file or folder in such a way as to *shorten* the path? In
other words, even though I got erroneous prompts for a
password that didn't exist, do you think that the issue
still has something to do with the length of the pathname?
Or are you saying that simply renaming the file or folder
-- even if the new name is the same length as the old one
-- is doing something mysterious behind the scenes that
eliminates the Password issue?
Despite having done some research in books and online, I
don't know what the limit is for the number of characters
in a PATHname or the limit on the number of folder levels
(if there is one), but I believe that the limit in XP on
the FILEname itself is 260. The thing that puzzles me is
that the entire PATH to one of the problem files is only
about 166 characters long, including spaces. So, I can't
figure out why Windows error messages yesterday told me
that the "filename" (actually referring to the pathname in
my case, I believe) was too long.
George
>-----Original Message-----
>Had a similar problem copying backups across a network
once, only
>surefire answer I found was to rename the offenders. BTW,
if you're
>saving HTML files and their images, you can save them as .
MHT or web
>archives which put the images and HTML in a single,
shortnamed file.
>
>George wrote:
>> Airman PD,
>>
>> I tried your suggestion, and it helped, at least in a
>> theoretical sense, but it also brought up some new
issues.
>>
>> First of all, I discovered by experimenting with copying
>> the top-level folder to my desktop that there were
>> *pathnames that were too long* (according to the error
>> messages I got) for Windows to handle. I do have about
>> seven levels of folders, so that did not totally
surprise
>> me. So, I temporarily removed those folders and files
with
>> the long pathnames, and then the Windows copying process
to
>> the Windows CD Burning folder worked.
>>
>> Then, I decided to try your Zip method using Windows'
>> built-in Zip utility. Well, everything -- *including*
the
>> previously mentioned folders with the pathnames that
were
>> too long -- copied over OK into the Windows zip file.
So,
>> presumably if I were to try to burn this using Windows'
CD
>> burning utility, I would not have the problem with data
>> loss (missing folders and files) that I had before.
>>
>> But, I discovered that any saved Web pages would not
open
>> the *images* that were saved in their corresponding "web
>> page filename_files" folder. Only the *text* of the
HTML
>> page was showing. A problem, but not too bad. So, I
>> extracted them. Well, when I extracted the whole
top-level
>> folder that had been zipped, I got a bunch of pop-up
>> messages prompting me to enter a *password* for many of
>> these files, as well as a few Word files. There are
*no*
>> passwords on any of these files or folders. So, I had
to
>> skip extracting those files and therefore lost dozens of
>> files.
>.
>
- Next message: Ken Blake, MVP: "Re: E-mail alert at start-up"
- Previous message: EGR: "Re: configuring a printer"
- In reply to: Airman PD: "Re: Reply to Airman PD -- Windows Zip folders failures"
- Next in thread: Airman PD: "Re: Reply to Airman PD -- Windows Zip folders failures"
- Reply: Airman PD: "Re: Reply to Airman PD -- Windows Zip folders failures"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
