What free software are you still missing?

[Bjorn Simonsen]

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

Re the syntax (NT/2k/XP/2003), trying to keep this as short as I can,
but that said - my *layman's attempt* at an explanation follows
(if I got any of this wrong, someone will hopefully tell us what's
right): It is a variant of UNC (Universal Naming Convention), handled
by the MUP - "Multiple UNC provider" (which I guess by *analogy* can
be said to operate sort of like a "DNS client" for the file system).
But the dot after the two slashes tells it the call is for the local
file system, not be directed to the DFS - "Distributed File System"
(again by *analogy*: sort of like a DNS server for the network file
system) - which it otherwise would - had the command contained a
server name instead of the dot. The advantage: skips normal path
parsing - including the check for reserved names (cf. articles). If
file exist locally, MUP establish a link for it and passes it to the
command used.

But this syntax/use does not work for deleting extremely long LFN
though - neither with RD nor DEL *.*, while both commands works fine
the normal way. Somewhat odd perhaps, although I would guess some of
the path-parsing it skips comes into play here, but anyway - that is
how it works (or not works) here. I guess the syntax/use can be useful
for the examples given in the articles though (like if a file happens
to be named with a reserved name like LPT1 and you want to delete it
etc).

As for various methods of handling bad names under NT/XP/2k,
a summary here:"You Cannot Delete a File or a Folder"
<http://support.microsoft.com/?kbid=320081> see fx under:
"Cause 4: Files Exist in Paths That Are Deeper Than MAX_PATH
Characters",
which mentions the 8+3 method Terry Russel mention (see resolution 1),
and the "rename above" method I've used (see resolution 2). Then also
"Use a Network Share That Is As Deep As the Folder" (see resolution 3)
- which I have never tried - #2 worked for me. Finally "Use a Tool
That Can Traverse Deep Paths" (see resolution 4), which I guess is
what I have been doing when using various commandline utilities (like
DIR/SED/DEL) to find and get rid of those very long file names. See
also under resolution 4, confirming what we have said about max_path,
"NTFS does not have this limit and it is capable of accommodating much
longer paths."

Now to try keep our focus; I would just love to hear about any
freeware apps that can in fact "traverses deep paths" as explained in
the above article. This includes of course any of the other freeware
renamers (other than "The Rename" I have already tried) : like do any
of them handle extremely long filenames (>260) even when the
shell/explorer don't? Although I would guess not, you never know (cf
the last mention article with its references to "The CreateFile API",
and what I noted about Unicode equivalent functions in the API
previously).

All the best,
Bjorn Simonsen

 

[Bjorn Simonsen]

omega wrote in <[email protected]>:

[...]

So the commandline SED was ideal for this, rock-sturdy and fast.
Your batch has now given me a good cleanup filelist.

I am glad you found it useful!

Is MSIE the only browser who does this, uses the abused title tag for the
file's save name? [...]

I think so, yes, at least I can not remember having tried any other
browser that did. (have not tried MYIE2, which you mentioned makes
this optional)

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.

[interesting case/illustration snipped for brevity]

Remember my initial post about several e-mails back and forth with a
AV company in 2001, who's client choked on those very long file names
I found back then? Let's just say I did not exactly feel very welcome
with my findings at the time...

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.

Yes very handy, and most certainly so with the over 100 handy
"one-liners" for SED collected and made available by Eric Pement at
his SED site <http://www.student.northpark.edu/pemente/sed/index.htm>.

Btw, in case you haven't read all the DOCs inside out yet ,
including the links in the FAQ at Eric Pement's site (I haven't
let me quote Al Aab, who once in alt.comp.editors.batch
placed SED - the Stream EDITOR - in perspective as follows:
<quote>
sed &
its dad: ed
& younger moron brother: edlin
& big brothers: vi, vm, ...
are line oriented
<quote>

Btw: do you remember in a previous thread, about your chm, when you
said you (felt you) had "cheated" with FAR, and I jokingly said
(something like) I was under the impression you did all your coding in
Edlin?

All the best,
Bjorn Simonsen

 

[Bjorn Simonsen]

But this syntax/use does not work for deleting extremely long LFN
though - neither with RD nor DEL *.*, while both commands works fine
the normal way.

should have been: "while both commands works fine with SFN's AND the
normal way"

All the best,
Bjorn Simonsen

 

[Baldie]

Visit: http://www.dirms.com/

Run dirms once every couple of months and then lett buzzsaw run
constantly. It defrags your HDD when there is inactivity on your PC