Terry Russell wrote in
If a name cannot fit on screen, it is too long.
long filenames , we can dream it for you .. wholesale
How does it handle files with paths >= 260 ?
I don't know, not tested.
You try (and let us know what you find if you do
while a path isn't supposed to be > 260 and filenames
can be 256
Not quite right, although I know many will consider names >260
characters long "illegal" as such. I will explain below.
it is easy to make such names and paths accessing these files
can then be a problem
Yes I know. I am familiar with the problem or the feature, which ever
way you look at it. First noticed this on my *Windows 2000* system
back in 2001.
First a disclaimer: I am not a programmer (if I was then I am sure my
reply would have been short and pregnant
- and it follows my
knowledge of the internal workings of Windows is limited. Hopefully
some of our programming fellow members here will correct me if I am
wrong or have simply misunderstood some of the basics.
Also, my notes here are based on notes from my findings (on my Win2k
system) from back in 2001. I have not looked into the issue (or
tested) since, in part since the "very-long-file-name problem" is not
a problem for me anymore. And in part this is so because of my batch
solution to find any such very-LFN (to rename by hand) before they
might become a problem. About my VLFN (Very Long File Names) batch
finder solution, see further below.
OK, how is >256 character filenames possible when under Windows
MAX_PATH=256 seems to have been the rule? Well if I am not mistaken it
is because the Win32 API is a house divided, divided into ANSI
functions and (some) equivalent Unicode functions. For the ANSI part
MAX_PATH=256 still applies. But for the Unicode part the max possible
path length increases to nearly 32000 characters or so. Some
limitations seem to be inherited though: Each path segment, such as a
directory name and individual file name, can not exceed 256 characters
on its own.
Long story short: I first became aware of the problem in 2001 when two
of my AV scanners failed to find and scan certain files (saved web
pages/images). One of the scanners would simply ignore (and not
report) the files, the other would choke on them. Reason - names
(path+filename=truenames) exceed the standard max_path value - and
well beyond that. After several e-mails back and forth (and some group
discussions elsewhere) one of the AV companies acknowledged the
problem - and told me, basically, their program (at the time!) did not
yet support the relevant Unicode functions...but that it would be
implemented soon. (the other company simply said they would look into
it - but I never heard from them again).
So reason you may experience that some programs/utilities/ - even some
of Windows own, may fail to handle/display/delete etc files with names
that exceed the MAX_PATH= 255 limitation, is probably they where never
designed to do that in the first place. They probably only use (call)
the standard ANSI functions, doesn't know the Unicode ones.
Some apps, like Explorer in my tests (back in 2001) would crash if I
attempted to delete or rename a >261 characters long filename directly
(Event viewer:
"The shell stopped unexpectedly and Explorer.exe was restarted.")
and would only work if the name was 260 characters or less.
(That Explorer could fail with "path to long" errors was known from
Win95 and NT, when expanding a server directory structure beyond
MAX_PATH, search for MS KB Q177665 if curios)
On the other hand I found a simple workaround that worked in all or
most cases: In Explorer (or other FM) rename the preceding path,
meaning - shorten one or several directory names above the file in
question - until the final truename is 260 characters or less.
How did I get those very long filenames in the first place?
Saving web pages with IE on my Win2k system! I found that while IE
only allowed max 260 character in the name field when saving,
it also ignored the preceding path while so doing.
But if you take preceding path + individual filename of (up to) 260
characters long, it means the truename (path+filename) can get very
long!
(as a side note: When you save web pages with IE and do not input a
name your self, IE use what ever it finds between the <Title> </Title>
tags in the page- and using up to 260 characters of that for the
filename to be saved. Some sites seems to want to cram all sort of
info into their page titles - for you to see when browsing the page,
or for search engines to find. So names of saved pages can get very
long by them selves that way. And the truename even longer of course
if you save those pages deep into an existing directory structure
and/or you in IE use save as "complete" - where IE saves images etc in
subdirectories. btw: That IE could cause such problems seems to have
been a known problem for some time, search for MS KB Q226446 if
curios).
As for testing - to know if such long names are present so you can
deal with them, here is a copy of my <VLFN.cmd> (short for Very Long
File Names), a batch script I created when I became aware of the
problem in 2001.
What it does, in short: List only those directories/files whose name
exceed 255 characters.
Copy of this below, for anyone to copy and use as they please, but at
their own risk of course.
(I am only using two drive letters in this
example for brevity - insert as many as you have/like).
VLFN.cmd (or VLFN.BAT, works the same)
<--------------cut below ------------->
IF EXIST max_path_warning.txt DEL max_path_warning.txt
pause
DIR c: d: /B /S | SED -n '/^.\{255\}/p' >>max_path_warning.txt
START max_path_warning.txt
<--------------cut above ------------->
You need SED (in your path) for this to work (about SED, see below).
The START line assumes you have a working Windows editor associated
with *.txt files (such as Notepad or any plain text editor). Also
notice the script might take some time to complete, depending on how
many drives/directories/files the DIR command (and SED) will have to
processes. Took 78 seconds last time I ran it on my 120GB drive
(checking C: through P: ).
Simply explained: The first line of the script is simply to delete any
existing "max_path_warning.txt" file, if it exist - since if it does
- any new info will be appended (>>) to the old - and I don't want
that. The DIR command then list all files on the given drives (here c:
d
while recursing subdirectories (/S), and using the bare format
(/B) for the outputting of names. The output from DIR does not show on
screen, but is instead "piped" (|) to SED which uses it as its input.
SED then does its magic, and prints only those names that exceed 255
characters. The output from SED does not show on scrreen in this case,
but is appended (>>) to a text file named max_path_warning.txt (if you
want it on screen instead, just remove the append/filename). The Start
command then invokes my Windows text editor - passing it the
max_path_warning.txt file to load. I can there see if any such file or
directories found, and if needed I can go about renaming them to
shorten them as explained elsewhere.
The above can of course be modified (including save as bat for Win9x)
to use as a "pre-cd-burning test" for >64 names also, on any given
path/directory. Just change the value (255) and the path (c: d
accordingly. You can of course also change the path statement (c: d
to %1, so that you can input the search path on the commandline,
for example such as
C:> VLFN "C:\my documents\Myfilestoburn"
if you want to search a different path each time,
About the SED syntax used in the above, well I do not claim
credit for that, so don't ask
I simply adapted it from
Eric Pement's extremely useful(!) collection of
"HANDY ONE-LINERS FOR SED (Unix stream editor)"
<
http://www.student.northpark.edu/pemente/sed/sed1line.txt>
there, under the heading
SELECTIVE PRINTING OF CERTAIN LINES:
I found:
# print only lines of 65 characters or longer
sed -n '/^.\{65\}/p'
For info about SED how to get it. See
Eric Pement's SED page and SED FAQ (faq in html or plain text):
<
http://www.student.northpark.edu/pemente/sed/>
<
http://www.student.northpark.edu/pemente/sed/sedfaq.html>
<
http://www.student.northpark.edu/pemente/sed/sedfaq.txt>
I have been running the above VLFN.CMD script every now and then ever
since I first become aware of the problem in 2001. But only on a few
occasions have I come across such very long filenames again. In in all
but one instance did I find these after having saved some webpages
with IE. (the exception was my own doing, so never mind).
All the best,
Bjorn Simonsen
