OVERLY LONG FILE NAMES - as impediment to COPYING FILES

"code_wrong" wrote:

>
> "EverymanEndUser" <EverymanEndUser.DeleteThis@discussions.microsoft.com> wrote in
> message news:4FA5815A-15E4-42AE-A079-B84B9F597A7F@microsoft.com...
> >I tend to use long file names, so as to identify needed files readily.
> >
> > If the file saves to my C drive in Windows XP Professional,
> > I don't pay particular attention to the length of the file name
> > that I've used.
> >
> > But in trying to COPY large files (e.g., a folder holding tens
> > of thousands of sub-folders, with 2GB of saved data), most
> > copying programs that I've encountered -- on 250 GB Maxtor
> > external hard drives, on 40 GB HP external hard drives,
> > on 2 GB Lexar flash drives -- not only will NOT COPY
> > a file with an overly-long file name, but they also TERMINATE
> > THE ENTIRE COPYING PROCESS INSTANTLY, merely on
> > hitting a single too-long file name.
> >
> > Going into huge saved data files MANUALLY and MANUALLY
> > reducing the length of each long file name is impossible.
> >
> > That's why we have COMPUTERS AND PROGRAMS:
> > to automate important but tedious tasks and processes.
> >
> > I am hoping that someone somewhere has
> > AN AUTOMATIC FILENAME-LENGTH TRUNCATION PROGRAM,
> > or subroutine -- that could be run through my entire C drive
> > prior to attempting to copy large files, or, even better,
> > that could be run ON-THE-FLY in conjunction with any
> > file-copying process, and that could truncate overly-long
> > file names on-the-fly, as they are encountered, to permit the
> > standard file-copying routines or algorithms to proceed
> > without stopping, and even without losing those particular files
> > with overlong names.
> >
> > IS THERE SUCH A FILENAME-LENGTH TRUNCATION PROGRAM?
> >
> > If so, how can I get an operational version, both for XP Professional
> > and for XP Media Center?
> >
> > I'd have thought that this sub-routine would have been the most
> > obvious thing in the world for MICROSOFT itself to have
> > incorporated into Windows.
> >
> > But if it's available in Windows XP Professional or in XP Media Center,
> > I'm not aware of it.
>
> google found this:
> http://www.foryoursoft.com/batchren2_a.htm
> I would not recommend mass truncating all the files on your hardrive ...
> there will no doubt be long file names in use by short cuts , other programs
> etc.. stick to truncating those files you want to copy
>
>
>

On Tue, 16 Aug 2005 09:28:06 -0700, EverymanEndUser

>I tend to use long file names, so as to identify needed files readily.
>If the file saves to my C drive in Windows XP Professional,
>I don't pay particular attention to the length of the file name
>that I've used.

As ye sow...

>But in trying to COPY large files (e.g., a folder holding tens
>of thousands of sub-folders, with 2GB of saved data), most
>copying programs that I've encountered -- on 250 GB Maxtor
>external hard drives, on 40 GB HP external hard drives,
>on 2 GB Lexar flash drives -- not only will NOT COPY
>a file with an overly-long file name, but they also TERMINATE
>THE ENTIRE COPYING PROCESS INSTANTLY, merely on
>hitting a single too-long file name.

Yep. There are two things at work here:

1) Total file spec length

The "file spec" is the full path to the file - not just the name, but
also drive letter, sequence of directories to be traversed, and then
the file name itself.

Now it may be that if you address the file name in a relative way,
e.g. "Very long name.jpg" which is inherently ".\Very long name.jpg",
the total length is OK. But access it via the full absolute path,
e.g. "Documents and Settings\Fred H Maroney\My Documents\My
Pictures\Fred's Holiday Photos from Spain, But Before The Rain\Very
long name.jpg" and you may hit the wall.

One way to kill this problem is to avoid MS's absurdly deeply-nested
data paths, i.e. move pictures to, say, C:\PICTURES.

You can also have problems where a file spec is OK when the base
directory is off the root, but too long when the whole subtree is
copied to a destination that is within a directory path, e.g.

Source: C:\
Object: Pictures\Blah\blah\blah\Very long name.txt
Destination: C:\Some\Really\Gratuitously\Long\Path

2) Varying file system rules

This kicks in when you're building a CDR or DVDR, because the name
rules for various CDR and DVDR formats are not exactly the same as
they are for Windows. For example, there may be different length
limitations, a prohibition on leading or trailing spaces, some
characters may be unsupported and converted to others, e.g. so that
!This-name.txt becomes _THIS_NAME.TXT, etc.

One way to manage this is to first archive the data in a .ZIP, which
will contain the names in perfect fidelity and hide them from the
target file system, then plonk the .ZIP onto the CDR or DVDR.

>Going into huge saved data files MANUALLY and MANUALLY
>reducing the length of each long file name is impossible.

Yep.

>I am hoping that someone somewhere has
>AN AUTOMATIC FILENAME-LENGTH TRUNCATION PROGRAM

There are a lot of tools that do this stuff, but be careful; you can
screw up royally. Here's a classic example; "change all occurances of
C:\ to D:\ and all occurances of D:\ to C:\"...

For all C:\, replace with D:\
For all D:\, replace with C:\
hey! why is *everything* C:, now??

So I'd use something like CK Rename. This shows you "before" and
"after" as you try out different bulk naming operations, before you
actually apply them. Far more accident-proof!

>that could be run through my entire C drive

That's uber-dumb. I'd work under direct vision, or strictly within my
own data subtrees; I'd never let loose something like this at files
that I didn't know what they were ot what they were supposed to be
called. Remember that even if you keep an undo path, the order in
which LFNs are (re)named will kick the underlying 8.3 names around,
and that matters as some parts of the system rely on those. Do a
search through the registry for ~1, if you doubt that!



>-------------------- ----- ---- --- -- - - - -
Tip Of The Day:
To disable the 'Tip of the Day' feature...
>-------------------- ----- ---- --- -- - - - -