Path: ...!3.eu.feeder.erje.net!feeder.erje.net!weretis.net!feeder8.news.weretis.net!news.mb-net.net!open-news-network.org!.POSTED!not-for-mail
From: Marcel Mueller <news.5.maazl@spamgourmet.org>
Newsgroups: comp.unix.programmer
Subject: Re: Long filenames in DOS/Windows and Unix/Linux (Was: Piping to
 stdin)
Date: Sun, 1 Sep 2024 11:44:16 +0200
Organization: MB-NET.NET for Open-News-Network e.V.
Message-ID: <vb1d1h$chc$2@gwaiyur.mb-net.net>
References: <9e7a4bd1-bfbb-4df7-af1a-27ca9625e50bn@googlegroups.com>
 <ubg6o7$3jrsn$1@news.xmission.com> <ubg853$2ssj8$1@dont-email.me>
 <ubg8a8$2t20l$1@dont-email.me> <vaubbo$1d324$1@news.xmission.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 1 Sep 2024 09:44:17 -0000 (UTC)
Injection-Info: gwaiyur.mb-net.net;
	logging-data="12844"; mail-complaints-to="abuse@open-news-network.org"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:LkNFwOINov+qGnjv+JyRvyHV+Rc= sha256:Fe2psHRO/fLSZduc4V3XTvsBus1pv+a9LWejYjAN3bo=
	sha1:K2UZBXFfU+bQn4e6sjD9BK7HuqI= sha256:80wJqwXFOdT6S7BtK5d0sp87JSspqtdHylHSXN0E0Gk=
Content-Language: en-US
In-Reply-To: <vaubbo$1d324$1@news.xmission.com>
Bytes: 3467
Lines: 47

Am 31.08.24 um 07:57 schrieb Kenny McCormack:
>      2) Spaces in filenames are pretty much a necessity from the end-user
> 	POV (but see below).  Yes, it makes things hard for us on the admin
> 	side of the game.  I have always thought that the right answer is
> 	to have both - a short name that is usable for the admin side of
> 	the game and a long label that the user can work with.  There are
> 	two solutions of this nature that I like:
> 	    a) The "Extend a name" idea.  Where you have short names at the
> 		filesystem level, but then have a database linked to that
> 		that allows the user to think that long, descriptive
> 		filenames are supported.
> 
> 		A long long time ago, there was a DOS product called
> 		"Extend a name" that did this.  Also, 4DOS (and later
> 		versions) does this.

OS/2 also had the "display file name" approach for invalid file names.

> 	    b) The way VFAT does it (and NTFS emulates) - where, for any
> 		file with a long name, there is an 8.3 filename (usually
> 		with weird characters in the filename) as well, and either
> 		filename is usable by programs.  This is one place where I
> 		think Windows really gets it right (and Unix could learn
> 		from it).
> 

In fact both variants caused at least as much problems as they solved.

First of all the relation between the two file names is usually lost, if 
a system that is not aware of them is used to move or copy a file.

Secondly the raw file names in the backend can cause significant false 
positives with wildcard matching. E.g. when you delete *2.txt it is 
likely that a bunch of mangled file names match too.

Last but not least sometimes the display file name is used to translate 
system folder names into the users language. Besides the false positive 
problem this makes it difficult to find the raw name for the user.
(Of course, translated system folders like "Programme" or 
"Arbeitsoberfläche" caused other problems.)

At the end I always disabled the two file mane approach wherever 
possible. (NTFS, Samba ...)
If an old OS is not aware of accessing certain file names, it should not 
be used for this kind of data.


Marcel