Folder \ File Name Convention

[BeeJ]

My archive app creates folder names and file names based on the process
so I can see at a glance how the folder and/or file was created. e.g.
Zip type, encryption etc.

Is there a naming convention for naming folders and files?

Is 253 the correct max length for both files and folders. Does that
include the file name extension? i.e. is there a new 8.3 convention
now? Is there a proper way to truncate or otherwise shorten folder or
filenames that are too long?

I know that I can name files this.and.that.ext
That comes in handy.
I also know that Rename can create filenames that Windows will show and
use but are not totally compatible with some of windows operation.
I sometimes us the temporary filename e.g.
.~WIPE~
Yes dot~WIPE~
It all works (so far).

If I use ~ as in short filenames for truncating long file or folder
names will that cause a problem with windows? i.e. will it try to
fiddle with it.

[ralph]

On Fri, 03 May 2013 15:32:59 -0700, BeeJ <spa...@nospam.com> wrote:

>My archive app creates folder names and file names based on the process
>so I can see at a glance how the folder and/or file was created. e.g.
>Zip type, encryption etc.
>
>Is there a naming convention for naming folders and files?
>

Nope.
You can do whatever you want. However, from a practical standpoint you
probably want to avoid extension already in use. ie, an application
that uses the extensions - .com, .accdb, .jpeg, htm, for example, - to
publish its data, is likely to annoy someone sooner or later.

>Is 253 the correct max length for both files and folders. Does that
>include the file name extension?

Yes, any extension is included in the total count.
Older references say 255 is max length. You will find this often set
as a constant in many libraries. Newer documentation will give the
maximum length of 260. You'll find a number between 254-260 -
depending on where (and when you look).

In practical usage, you will probably want to use something much
smaller to avoid problems if copying (sending) or backing up a file.

> ... i.e. is there a new 8.3 convention

>now? Is there a proper way to truncate or otherwise shorten folder or
>filenames that are too long?
>

There is a conversion of long filenames to 8.3 format "convention" -
http://support.microsoft.com/kb/142982

But note, that convention is use by the file system to produce a 8.3
formatted filename that are compatible with DOS applications. The
convention creates unique filenames that are unique within the current
(local) context, they are not guaranteed to be unique if passed to
another file system. ie, it was not/is not something to be fiddled
about by a developer. (If you did have to store and use on a 16-bit
O/S, better off creating your own shortnames.)

You are welcome to invent your own.

>I know that I can name files this.and.that.ext
>That comes in handy.
>I also know that Rename can create filenames that Windows will show and
>use but are not totally compatible with some of windows operation.
>I sometimes us the temporary filename e.g.
>.~WIPE~
>Yes dot~WIPE~
>It all works (so far).
>
>If I use ~ as in short filenames for truncating long file or folder
>names will that cause a problem with windows? i.e. will it try to
>fiddle with it.
>

No. All valid characters are useable. Any extension length is useable.
Outside of DOS/CMD, other shell, or 3rd party app's - command line or
input *parsing* - there is no special meaning associated with any of
them.

[Ulrich Korndoerfer]

Hi Ralph,

ralph schrieb:

> ...

> In practical usage, you will probably want to use something much
> smaller to avoid problems if copying (sending) or backing up a file.
>

A remark: NTFS in general is better suited to handle "long" filenames
and especially "long" pathes. Problems may arise when files with "long"
filenames are copied from or to another type of filesystem.

There are some pitfalls though, especially with newer WIN-OSes where eg
the character sequence "setup" triggers the OS to treat such files special.

Also spaces embedded in a file name will lead some applications (most
often OSS or UNIXoid ones) to misbehave.

And again problems may arise when copying from NTFS to another type of
file system. Eg a leading dot has special meaning in UNIXoid systems.

--
Ulrich Korndoerfer

VB tips, helpers, solutions -> http://www.prosource.de/Downloads/
MS Newsgruppen Alternativen -> http://www.prosource.de/ms-ng-umzug.html

[BeeJ]

regarding the 8.3 conversion.
I do not expect to have to use that conversion but when you talk about
other systems do you mean unix for example.

Will the 8.3 conversion be ok if the file is copied to a NAS or from
Win 7 PC to Win XP PC?

Thank you for the information. As you indicated the max number seems
to be different where ever I look and that is why i am thinking of
settling on 253.

I will post my code if you want to look at it.
Right now I set max path length to be 253 - 12. 12 from 8.3 minimum
length filename. I error out if the path name is over 253 or I cannot
get a unique filename since right now I do not know what else to do.
I am not using the conversion, just shortening the basename length by
truncating.
I cannot control the subfolders that a user might set up therefore I
cannot control the pathname length.

Dose the converted 8.3 filename contain control or extended characters?
Could I do that also with 'name as'. that might be fu to play with.

[BeeJ]

> Hi Ralph,
>
> ralph schrieb:

>
>
> A remark: NTFS in general is better suited to handle "long" filenames and
> especially "long" pathes. Problems may arise when files with "long" filenames
> are copied from or to another type of filesystem.
>
>

> There are some pitfalls though, especially with newer WIN-OSes where eg the
> character sequence "setup" triggers the OS to treat such files special.
>
> Also spaces embedded in a file name will lead some applications (most often
> OSS or UNIXoid ones) to misbehave.
>
> And again problems may arise when copying from NTFS to another type of file
> system. Eg a leading dot has special meaning in UNIXoid systems.

I do not plan to be off world.
I will keep that in mind. Thank you.

[Phil Hunt]

I sometime have trouble with file name that are not in English. eg. MS word
doc. I have to rename to something before word can open it. Any insight on
why ?

[ralph]

On Sat, 04 May 2013 10:37:20 -0700, BeeJ <nos...@spamnot.com> wrote:

>regarding the 8.3 conversion.
>I do not expect to have to use that conversion but when you talk about
>other systems do you mean unix for example.
>
>Will the 8.3 conversion be ok if the file is copied to a NAS or from
>Win 7 PC to Win XP PC?
>

I probably shouldn't have even brought it up. But since we are there
... <g>

The "8.3 conversion" is purely an O/S thing. You can not *do* the
conversion - it is done for you. And when examined in the context of
the over-all possible platforms and/or utilities that may be involved
can get quite complex. Add to that, there have been subtle differences
changes across the evolution of Windows platform (and to some extent
possible configurations - ie, registry settings).

For example, with earlier O/Ss (FAT) that started allowing long
filenames, the longer filename was sort of a hack - the 'real'
filename was a generated short 8.3 - the long name an artifact.
Starting with Windows 2000 (NTFS) the long name became the 'real'
name, and the short name the artifact. (And it was possible to
turn-off automatic short-names for specific NTFS volumes.)

Here is one example where mix of long and short can be trouble.

Say in the Finance folder on Windows 98 BoxA you have the files
Accounts For 1985.dat (Accoun~1.dat)
Accounts For 1986.dat (Accoun~2.dat)
In the Finance folder on Windows XP BoxB you have ...
Accounts For Harry.dat (Accoun~1.dat)
Accounts For Tom.dat (Accoun~2.dat)

Now copy the files from BoxA to BoxB. Depending on media it might be
an adventure.

To simulate a 16-bit or non-longfilename-aware utility. Type COMMAND
and DIR in DOSPrompt window.

Ten years ago the sites were full of problems and gotchas with various
utilities, wire, and applications, but it has all pretty much sorted
itself out by now. In general just ignore the "8.3 conversion" -
accept it's there if you need one, otherwise fortget they or the
convention ever existed. <g>

>Thank you for the information. As you indicated the max number seems
>to be different where ever I look and that is why i am thinking of
>settling on 253.
>

I have no documentation but I've always guessed the change from 255 to
260 came with the addition of "https://" as a "volume" signature.
(five extra over "C:\"). Also you will note the docs usually describe
260 characters as a *PATH* limit, and 255 as the *filename* limit.

Windows has always had a four-segmented view of filepathnames.
as in -> <Volume> <Path> <filename> <extension>

>I will post my code if you want to look at it.
>Right now I set max path length to be 253 - 12. 12 from 8.3 minimum
>length filename. I error out if the path name is over 253 or I cannot
>get a unique filename since right now I do not know what else to do.
>I am not using the conversion, just shortening the basename length by
>truncating.
>I cannot control the subfolders that a user might set up therefore I
>cannot control the pathname length.
>

When I was working with a company that often had extreme hierarchies,
long names and amazing volumes - we settled on a standard much lower -
132 characters in fact. (The width of fan-fold paper.) Anything
longer and sooner or later we hit a snag.

>Dose the converted 8.3 filename contain control or extended characters?

No. The first time Windows does is remove all non-alpha (or non-digit)
characters from the name. As the name is in Unicode there can actually
be any number of strange characters - the conversion removes them as
well.

[Farnsworth]

"BeeJ" <nos...@spamnot.com> wrote in message
news:km3h0b$un2$1...@speranza.aioe.org...

> regarding the 8.3 conversion.
> I do not expect to have to use that conversion but when you talk about
> other systems do you mean unix for example.
>
> Will the 8.3 conversion be ok if the file is copied to a NAS or from Win 7
> PC to Win XP PC?
>
> Thank you for the information. As you indicated the max number seems to
> be different where ever I look and that is why i am thinking of settling
> on 253.

Why the basic questions? Check the first parameter of CreateFile function,
and then click on "Naming Files, Paths, and Namespaces" link described in
that parameter:

http://msdn.microsoft.com/en-us/library/windows/desktop/aa363858%28v=vs.85%29.aspx

See also for Windows and other OS'es:

http://en.wikipedia.org/wiki/Filename

> I error out if the path name is over 253 or I cannot get a unique filename
> since right now I do not know what else to do.

If you want to create unique files, then use GetTempFileName(). This
function creates a file with a guaranteed unique name, then closes it, and
gives you the file name(You need to set uUnique parameter to 0):

GetTempFileName function:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa364991%28v=vs.85%29.aspx

[BeeJ]

> I have no documentation but I've always guessed the change from 255 to
> 260 came with the addition of "https://" as a "volume" signature.
> (five extra over "C:\"). Also you will note the docs usually describe
> 260 characters as a *PATH* limit, and 255 as the *filename* limit.
>
> Windows has always had a four-segmented view of filepathnames. as in ->
> <Volume> <Path> <filename> <extension>
>

> When I was working with a company that often had extreme hierarchies,
> long names and amazing volumes - we settled on a standard much lower -
> 132 characters in fact. (The width of fan-fold paper.) Anything
> longer and sooner or later we hit a snag.
>
> Dose the converted 8.3 filename contain control or extended characters?
>
> No. The first time Windows does is remove all non-alpha (or non-digit)
> characters from the name. As the name is in Unicode there can actually
> be any number of strange characters - the conversion removes them as
> well.

Slight miscommunications. In one case I am talking about the API
convert and in the other about my doing the conversion by truncating
and substituting e.g. extended ASCII character (on a whim). I rember
that I can create filenames that Windows does not know how to process.
That was a while back and maybe that has been "fixed".

Thanks for the additional info.

[BeeJ]

People present the information is a different way so I get human input
that I better digest. Yours included.

Thanks for your input and the API I did not know about. i have to try
it out.

But as you have read, in some case a path length will be so long
(incudes subfolders) that there is nothing left for a filename.
So the only resort is to raise an error. (just thinking out loud).

I have written a method to create a unique filename based on a current
filename such that it retains the current filename and suffixes a (nnn)
to keep a file history (an option is also to overwrite).

[ralph]

On Sun, 05 May 2013 07:45:04 -0700, BeeJ <nos...@spamnot.com> wrote:


>
>Slight miscommunications. In one case I am talking about the API
>convert and in the other about my doing the conversion by truncating
>and substituting e.g. extended ASCII character (on a whim). I rember
>that I can create filenames that Windows does not know how to process.
>That was a while back and maybe that has been "fixed".
>

It is possible to provide an filename with illegal characters, but
that has nothing to do with the "8.3 conversion" process. Other than
opening up COMMAND is one way of getting rid of such files. (the
characters will be expunged)

-ralph

[BeeJ]

Again, my 8.3 conversion not the API conversion.
Thanks for the feedback and clarification.

[ObiWan]

> Is 253 the correct max length for both files and folders. Does that
> include the file name extension? i.e. is there a new 8.3 convention
> now? Is there a proper way to truncate or otherwise shorten folder
> or filenames that are too long?

See

http://support.microsoft.com/kb/177665

and also

http://msdn.microsoft.com/en-us/library/windows/desktop/aa364989%28v=vs.85%29.aspx

"In the ANSI version of this function, the name is limited to MAX_PATH
characters. To extend this limit to 32,767 wide characters, call the
Unicode version of the function and prepend "\\?\" to the path. For
more information, see Naming Files, Paths, and Namespaces."

HTH

[Tony Toews]

On Sat, 04 May 2013 18:10:41 +0200, Ulrich Korndoerfer
<ulrich_wa...@prosource.de> wrote:

>A remark: NTFS in general is better suited to handle "long" filenames
>and especially "long" pathes. Problems may arise when files with "long"
>filenames are copied from or to another type of filesystem.

Problems can also arise when you copy a long path & file name to a
server share. It may appear to be shorter than ~255 characters but on
the server OS it may be considerably longer once it's on the server
file system.

That is you may see \\server\share\short folder\etc. But the server
share may be based on M:\this is a long folder name\long sub folder
name\another long subfolder name\share name.

I suspect most folks know this but I thought I'd mention this just in
case.

Tony
--
Tony Toews, Microsoft Access MVP
Tony's Main MS Access pages - http://www.granite.ab.ca/accsmstr.htm
Tony's Microsoft Access Blog - http://msmvps.com/blogs/access/
For a convenient utility to keep your users FEs and other files
updated see http://www.autofeupdater.com/