[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn co win32 and linux filesystem compatibility question

From: Scott Palmer <scott.palmer_at_2connected.org>
Date: 2006-01-06 20:03:22 CET

On 6-Jan-06, at 11:25 AM, Brad wrote:

>> Oh, another thing you can't do on Windows is have a file name
>> ending with a period. If there isn't anything after the period
>> the period gets removed.
>
> Actually, no Windows file name actually has a "." character in it,
> at least not the one denoting an extension. That's a display
> element only. The directory entry itself does not contain the "."
> character, unless it's a so-called "long" file name with a period
> embedded in it.

Do you mean for the 8.3 names? So-called "long" file names are the
only kind I use. You can actually turn off the creation of the 8.3
names with a registry setting, though I haven't bothered to do that.
It should probably be the default setting by now given the ridiculous
nature of having two names for the same file, one that you can't even
control. That "backwards compatibility" hack was certainly
backwards and a huge mistake in my opinion. Microsoft just can't get
their head out of the early 1980s. (Even then they had the shortest
file names going, other systems like the Commodore 64 used 16
character names :) )

Keep in mind that the restriction that a file "extension" be only 3
characters was removed long ago as well. Though for some stupid
reason we still see files ending with .htm instead of .html and other
silly cases.

Anyway, I'm curious if the "long" (i.e. normal) file names are
allowed to end with a period, or if this restriction is enforced only
by the shell.

Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 6 20:07:46 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.