What free software are you still missing?

[Anne]

Bjorn Simonsen said:

2) In option/modification specify 64
in the "Maximum filename length" field
and enter the expression: %f
in the expression combo

If one needs to shorten filenames often, the above-mentioned method is
the best and perhaps the most reasonable solution, not to mention the
easiest, too. It automatically shortens all filenames to 64 characters, and
if you use '%f' expression, dot + extension are included in the count.
Clever.

 

[Bob Adkins]

No one. The hold you have to apply - and it's from behind - is the
so-called "sleeper". The only hold, if properly applied, from which
there is no escape. Fifteen seconds or less and your opponent is safely
subdued in la-la land. Of course he won't be able to answer your
questions for a few minutes. But you can bet he will when he comes to.

Why not just use the Vulcan shoulder pinch?

The heads side of a coin is - in the USA - heavier. Someone who's job it
was to flip a coin a few thousand times found out that the heavier side
lands face-down a little over 50 per cent of the time.

That could be me. When I answer a question on this news group, I flip a coin
for what my answer will be.


Bob

Remove "kins" from address to reply.

 

[Terry Russell]

Terry Russell wrote in


I don't know, not tested.
You try (and let us know what you find if you do


Not quite right, although I know many will consider names >260
characters long "illegal" as such. I will explain below.

It varies, which is part of the problem.
Often webpages etc have unnecessarily , even insanely , long names
and paths.

e.g.
"The protected-mode FAT file system allows filenames of up to 256
characters, including the terminating null character. In this regard, it is
similar to the Microsoft® Windows NTT file system (NTFS), which allows
filenames of up to 256 characters. Protected-mode FAT allows directory paths
(excluding the filename) of up to 246 characters, including the drive
letter, colon, and leading backslash. This limit of 246 allows for the
addition of a filename in the standard 8.3 format with the terminating null
character. The maximum number of characters in a full path, including the
drive letter, colon, leading backslash, filename, and terminating null
character, is 260."

But that doesn't say it all.

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.
....
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!

Thats what the example illustrated ;-)

....

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.

You are essentially correct, there are some other twists,

'Invalid' paths and file names may report only a shortname, usually if
long access fails you can still use the shortname to manipulate the file,
the problem is knowing whether the file manipulation API is using the
filename, or the name of the filename ;-)


The main point is very long filenames and tree depths are best avoided,
the directory and filename structure is largely unchecked and easily
mangled.

 

[Terry Russell]

181 lines for your bio and a batch file. Find the right group and a
signature.

Okay, we will take our landmine signs and go elsewhere.

 

[Bjorn Simonsen]

181 lines for your bio and a batch file. Find the right group and a
signature.

Anybody else that thinks my message was irrelevant under the subject
of freeware File Renamers that can shorten long filenames? If I'm just
wasting my time sharing what I considered very relevant info for the
subject at hand, let me know people...

All the best,
Bjorn Simonsen

 

[omega]

[...]
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.

I used to get those from a like operation: clicking "add to favorites,"
and not first truncating the name. Now I don't get them. Websites haven't
improved at all: they still abuse the <title> tag to write out six page
of spammy self-promotion crap. My own habits might have improved a little,
but not completely. I think MSFT might have fixed the MSIE problem, and
now automatically truncates the names to a less problematic state. I'm
leaving that thought as idle speculation...don't want to do a mskb search
for whether it was an official bugfix.

Another problem I get is bad characters in the names. A more common one
being the copywrite symbol. Characters that are not compatible with my
commandline ops. Regularly a difficulty for deltree.exe, which I use a
lot.

(the exception was my own doing, so never mind).

I had a test bat file go wild one time, and copied a gazillion times a
folder path within itself. It took me over an hour of manual labor to get
rid of it. (None of the renamers etc can overcome that sort of thing.) I
had to start at the far right, and deltree, then move left(up) slowly,
deltree again, one step at a time. So very tedious! I almost get tired
from just the memory of that cleanup.

 

[omega]

I used to get those from a like operation: clicking "add to favorites,"
and not first truncating the name. Now I don't get them. Websites haven't
improved at all: they still abuse the <title> tag to write out six page
of spammy self-promotion crap. My own habits might have improved a little,
but not completely. I think MSFT might have fixed the MSIE problem, and
now automatically truncates the names to a less problematic state. I'm
leaving that thought as idle speculation...don't want to do a mskb search
for whether it was an official bugfix.

It does occur to me I could test this, for my MSIE 5.5 behaviour. Insert
x characters into the title tag of an htm, save on a slightly longer path,
and see if MSIE now truncates (if not to reasonable length, at least to
length that the OS/FS can handle). I'd have to queue the test for later
though (req'd to log off for external demands).

 

[dszady]

Why not just use the Vulcan shoulder pinch?

That would work. Pull the head back. Hammer fist to the nose for added
emphasis.

That could be me. When I answer a question on this news group, I flip a coin
for what my answer will be.

I have a feeling somewhere in this thread I'll get a response that I can
bet on.

 

[dszady]

Anybody else that thinks my message was irrelevant under the subject
of freeware File Renamers that can shorten long filenames? If I'm just
wasting my time sharing what I considered very relevant info for the
subject at hand, let me know people...

Calm down. You're ok. It's the length of the post. I read all of them
and almost all of them, except for the post where someone forgot to snip
and was jumped on for it. That person was a little touchy that day.

 

[Josiah Jenkins]

Why not just use the Vulcan shoulder pinch?


That could be me. When I answer a question on this news group, I flip a coin
for what my answer will be.

Sounds like a tail to me !

 

[omega]

[Snip some interesting stuff about Unicode and Ansi functions in file
names and path lengths]
[...]

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!

I believe the bug has been since fixed in later MSIE. I ran a test on
my MSIE 5.5 sp2 version. I used an .htm with some 1000 chars between
the title tags. Results:

The saved length did not exceed a 256 max. First save, it made a filename
of 243 chars in length; the other 13 for a path name. Second save, on a
long path name, MSIE truncated the filename was truncated down as necessary
(about 50 chars for the name, afterthe long path I used).

Earlier I'd commented that MSIE used to make horribly named .url files. On
the same test htm file, I tried the favorites function. Add to favorites,
MSIE automatically truncated to 127 chars. I believe that figure is preset
(the path to my MSIE favs folder is 24 chars). Second, when I tried to drag
to the explorer to create an .url file that way, I was turned down. The
refusal message said, "Error copying file. The system cannot find the path
specified."

btw: That IE could cause such problems seems to have
been a known problem for some time, search for MS KB Q226446 if curios).

I don't know about using the Offline Favorites function, as I'd unregistered
that part of MSIE on my system. But at least in the other ways, I think MSIE
is no longer committing these filename length felonies. I am glad I went to
that page, but for another reason. A click from there is an mskb article
giving a method deal with overlong paths. Use of the substitute command. Not
someting that had occurred to me.

[...]

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>

<--------------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 ------------->

<http://www.student.northpark.edu/pemente/sed/>

I downloaded Sed <http://sed.sourceforge.net/grabbag/ssed/sed-3.59.zip>,
dropped it into my path. I then tried to use your batch. I haven't rtfm'd
a single line of SED, instead figure I'll see if the error message means
anything obvious to you.

in
cmd /k DIR h: /B /S | SED -n '/.\{255\}/p' 1>>max_path_warning.txt
out
SED: -e expression #1, char 1: Unknown command: `''

I'd tried it first with my normal w99 command.com. Then next tried with
it with the 2000 command processor port: Win95Cmd.exe. Same error.

 

[omega]

Calm down. You're ok. It's the length of the post. I read all of them
and almost all of them, except for the post where someone forgot to snip
and was jumped on for it. That person was a little touchy that day.

I figured that was what you were in about. The principle about glasses
houses > stones. Fortunately, Mike, the recipient of that criticism,
seems to be very mellow/mature, and good about letting the waters flow
off.

Btw. And this is !!not a stone from my glass house. Your reader is config'd
to where it is repeating the whole subject header when it is changed.
Instead of just adding an OT to the existing subject line. Although for
this particular thread, about name lengths, the subject header has looks
that are most appropriate.

 

[omega]

in

cmd /k DIR h: /B /S | SED -n '/.\{255\}/p' 1>>max_path_warning.txt
out
SED: -e expression #1, char 1: Unknown command: `''

Bjorn, btw, that "1" near the end, it snuck into my clipboard somehow on
my way to the post. It was not in the .bat file I used. The only change
I'd made to the line you gave, it was to offer it only one directory at
a time, since two caused confusion with my command processor.

 

[omega]

I downloaded Sed <http://sed.sourceforge.net/grabbag/ssed/sed-3.59.zip>,

in
cmd /k DIR h: /B /S | SED -n '/.\{255\}/p' 1>>max_path_warning.txt
out
SED: -e expression #1, char 1: Unknown command: `''

It now occurred to me to read the error message. So I found out how to make
my command processor happier about that line. Changing the quote symbol.

DIR i: /B /S | SED -n "/^.\{255\}/p" >>max_path_warning.txt

I'd tried it first with my normal w99 command.com. Then next tried with
it with the 2000 command processor port: Win95Cmd.exe. Same error.

That 2000 command emulator is not supposed to emulate everything, so I'll
make guess that part of the excluded support to do with using a single quote
thing.

The result file, it turned up the filenames from today's msie test, since
those were 256 path+name. I'll now point the command at my large archive
drive. I think I'd long since cleaned up the bad names that MSIE generated
in earlier years, but it should be a handy way to make sure.

 

[John Fitzsimons]

Why do you suppose Flashget is adware/spyware? I use it very successfully. I
also run Adaware and Spybot regularly and they have never found any activity
from Flashget.

You obviously have an old version of FlashGet. See ;

http://www.amazesoft.com/reginfo.htm


" Your code will remove the advertising banners and shareware reminder
windows."

There is no need to pay for removing something that isn't there.

Regards, John.

--
****************************************************
,-._|\ (A.C.F FAQ) http://clients.net2000.com.au/~johnf/faq.html
/ Oz \ John Fitzsimons - Melbourne, Australia.
\_,--.x/ http://www.vicnet.net.au/~johnf/welcome.htm
v http://clients.net2000.com.au/~johnf/

 

[dszady]

Btw. And this is !!not a stone from my glass house. Your reader is config'd
to where it is repeating the whole subject header when it is changed.
Instead of just adding an OT to the existing subject line. Although for
this particular thread, about name lengths, the subject header has looks
that are most appropriate.

I had not even noticed it before. One little checkbox solved it.
Thanks.
BTW I wanted to delete those replies the second after I sent them to
him. Oh well.

 

[Bjorn Simonsen]

I believe the bug has been since fixed in later MSIE. I ran a test on
my MSIE 5.5 sp2 version. I used an .htm with some 1000 chars between
the title tags. Results:

The saved length did not exceed a 256 max. First save, it made a filename
of 243 chars in length; the other 13 for a path name. Second save, on a
long path name, MSIE truncated the filename was truncated down as necessary
(about 50 chars for the name, afterthe long path I used).

I have tested it with IE 6.0 now too. Had to install it on my test
setup first. IE 6.0 truncates also. This is good news. Since I don't
use IE very often my self, I have not payed much attention to the
updates for it - what they fixed etc. Even if the very-LFN problem is
still there (some "loop holes" left), now that IE seems to be fixed
those very long filename will probably not be very common or frequent
(unless some hacker/virus etc exploits it). Btw: One such "loop hole"
allowed me to try "The Rename" on 264 characters long file name when
Explorer could not delete it, but no go - see my reply to Terry
Russell about that.

Earlier I'd commented that MSIE used to make horribly named .url files. On
the same test htm file, I tried the favorites function. Add to favorites,
MSIE automatically truncated to 127 chars. I believe that figure is preset
(the path to my MSIE favs folder is 24 chars). Second, when I tried to drag
to the explorer to create an .url file that way, I was turned down. The
refusal message said, "Error copying file. The system cannot find the path
specified."

Not tried w/favorites..but Explorer seems to be fixed also. I think
maybe the most relevant updates must have been done there. As
explained - in the past I would use Explorer to shorten very long
names (rename above). Still can, but back then I could also do the
reverse, use it to create a filename that exceed maxpath by increasing
the length of directory names above the file in question. No longer
can, as you found: Explorer gives a warning/error message if I try.
Still can move a very long file into an existing directory though,
to create a inaccessible LFN. And Explore still can not delete a such
a file. But at least now it helps prevent them being created in some
ways (even if not all).

SED: -e expression #1, char 1: Unknown command: `''

I have seen your other message about it. Good that you found the
single quote character was causing it and the standard double quote
fixed it.

All the best,
Bjorn Simonsen

 

[Bjorn Simonsen]

Terry Russell wrote in

Thats what the example illustrated ;-)

Yes I know, irony is I snipped it for brevity. Btw see my other reply
of today to Karen (omega) about Explorer and IE now improved regarding
this. Only some loop holes remains it seems. Such as the one you
illustrated. I've used that method before, and used it again now to
test "The Rename". Test to see if it can rename a very long filename
when the GUI shell (Explorer) can not.

Created a 264LFN. Then after having verified Explorer could not delete
it, I tried "The Rename": First using free form method (expression).
Nope - filename to long it says - same as Explorer. Then tried the
"monitor long filenames" option (auto rename files that exceeds
certain limit, set to find >255 and auto-truncate at 250). But still
no go. So it seems if the system (GUI shell/explorer) can not handle
it, nor can the The Rename,. It behaves as most of the other utilities
I tried when I first ran into the problem in 2001. File is simply seen
as illegal or invalid it seems. Deleting it from the commandline still
works though, as it did back then.

Interestingly, in its preview window (click toolbar button after
selecting some files) The Rename offers a couple of checks, for
example "Find Long Names" (separate setting for this in registry,
default is 64), "Validate Filenames" (search for invalid characters in
filenames) and few others. Tried all of them on the very-LFN, and a
bit to my surprise it was given a OK, even on the LFN test. Anyway, as
long as names are not extremely long as in this case, I assume those
other features in The Rename might come in handy, such as the check
for illegal characters in names. I sometimes get them, and usually
have to drop to the commandline to handle it. I guess using the The
Rename can be faster in some such cases, like if you have more than
simply one or two illegal names that needs taking care of. When this
is said, I have yet to try this feature to see if they really work, I
mean on names that is not too long but otherwise illegal/invalid.

One problem with my batch solution: it depends on the output of DIR.
What DIR can't see (if anything) it can't see. But so far DIR seems to
have coped, or so I like to belive. I can not be sure of course. Btw I
have not been using DIR from Win2k my self for this, but 4NT by
Jpsoft. Thus why I allow my self not to doubt the output of Dir that
much. Still, 4NT is also limited by what the OS allows it to see - so,
no way to be absolutely sure I guess... unless one use something to
read the filesystem/disk directly.

You are essentially correct, there are some other twists,

'Invalid' paths and file names may report only a shortname, usually if
long access fails you can still use the shortname to manipulate the file,
the problem is knowing whether the file manipulation API is using the
filename, or the name of the filename ;-)

Yes, when name when alias. I only know for sure that system actually
use many of the short names (aliases) when booting/starting, so one
wold not want to "mangle" short names either - like with Xcopy - see
about this in: <http://www.xxcopy.com/xxcopy03.htm> and

The main point is very long filenames and tree depths are best avoided,
the directory and filename structure is largely unchecked and easily
mangled.

Yes of course. I never asked for this in the first place, my
AV-clients and IE brought it to my attention long time ago, and you
did again now , but as explained I have liked to think my batch
finder have helped prevent any such very-LFN residing on my system
long enough to become a problem.

All the best,
Bjorn Simonsen

 

[omega]

I have tested it with IE 6.0 now too. Had to install it on my test
setup first. IE 6.0 truncates also. This is good news. Since I don't
use IE very often my self, I have not payed much attention to the
updates for it - what they fixed etc. Even if the very-LFN problem is
still there (some "loop holes" left), now that IE seems to be fixed

I'd say it's no longer committing filename length felonies -- but that it
is an standing offender at the serious misdemeanor level. Saving web pages
with titles some 200+ chars in length, and the tiny little .url files with
127 spammy chars? GROSS. It's not just the practical problem of user later
moving those to a deeply nested directory. It's the outrageousness of their
length, and the ugliness.

I ran your SED batch on my archive disk. I didn't find anything illegal.
So then I changed the length seek number, to 200, to get a list of stuff
still overlong. In earlier times, I had already cleaned up my MSIE stuff
for the most part, by pointing my renamer utility at certain directories,
specifying extensions, and telling it truncate length to do. But there's
no way I'd try to point a renamer at that entire disk (70g data), and
expect my computer to not pass out. So the commandline SED was ideal for
this, rock-sturdy and fast. Your batch has now given me a good cleanup
filelist.

Is MSIE the only browser who does this, uses the abused title tag for the
file's save name? The Mozilla line, I think it uses the filename title.(?)
Even MyIE2, it offers an extra choice for save, letting you bypass the
intrinsic Browser Control's save-as dialog. But I think only for html,
no pics, and no source URL written in. I don't mind use of title instead
of filename per se, as it means having to spend less time oneself in having
to come up with a names to use for all those pages called index.htm. However,
what MSFT needs to do, it's to preset max length (in fav commands too) down
to something nearer the perimeter of civility.

those very long filename will probably not be very common or frequent
(unless some hacker/virus etc exploits it).

One of the first times I'd paid attention to someone reporting the problem
(it was on the pcmag message board), and they got it as a Kazaa lite user.

It is a very long file name that was apparently a download from some
peer sharing program because the folder this email automatically
installed on my computer was Kazaa lite/ sub folder My shared files.
[...] but when I get the error in explorer it says cannot find
Pokemo~2.bmp.

A responder at the time noted that a web search turned up a great number
of hits for others having problems with that particular file. I got the
impression that malice was not involved. Just some bad initial naming,
then the file sharing program wrote illegal length to everyone's disk.
I don't know any technical details, not used or paid attention to file
sharing programs, and cannot speculate why Windows allows illegal file
lengths to get written in that situation.

Btw: One such "loop hole" allowed me to try "The Rename" on 264 characters
long file name when Explorer could not delete it, but no go - see my reply
to Terry Russell about that.

I'm believe none of the renamers can deal with the excess lengths, and that
it's a task strictly for the commandline. And once there, having to use the
more serious tricks. Btw, I noticed a syntax new to me. For dealing with a
not unrelated subject, reserved names:

RD \\.\<driveletter>:\<path>\<directory name>

http://support.microsoft.com/default.aspx?scid=kb;en-us;315226&Product=winxp
http://support.microsoft.com/default.aspx?scid=kb;EN-US;120716

[...]

Still can move a very long file into an existing directory though,
to create a inaccessible LFN. And Explore still can not delete a such
a file.

I have some fairly deeply nested paths (but not outside the OS/FS limits)
and need them that way. So my primary safety measure is to keep my file
names within reasonable length. The excess ones that I have gotten were
almost all MSIE's doing.

The only routine time I "type an essay" for a filename, it's with
screenshots. I am usually in the middle of something else when I take
them, and don't want to distract my attentions by going through any extra
dialogs for annotations. But I can clean up these names at later stage
easily enough (all the same extension, and there are not that many).

[...]

I have seen your other message about it. Good that you found the
single quote character was causing it and the standard double quote
fixed it.

The batch works very nicely. And thanks for the pointer to SED. I see
that it's one of those venerable old warriors. I've downloaded the docs,
and might here and there rtfm a line or two. It's good to have on board
those tools that are strong and capable for text processing.

 

[omega]

Now, lets talk about directory tree depths > 64 ;-)

Is there a simple util or script that could tell me if any of my paths
were getting near the outer reaches?