From: "Albert D. Cahalan" <acahalan@cs.uml.edu>
Message-Id: <200206092205.g59M571515016@saturn.cs.uml.edu>
Subject: Re: vfat patch for shortcut display as symlinks for 2.4.18
To: nmiell@attbi.com (Nicholas Miell)
Date: Sun, 9 Jun 2002 18:05:07 -0400 (EDT)
Cc: phillips@bonn-fries.net (Daniel Phillips),
        adelton@informatics.muni.cz (Jan Pazdziora), christoph@lameter.com,
        linux-kernel@vger.kernel.org, adelton@fi.muni.cz
In-Reply-To: <1023658610.1518.12.camel@entropy> from "Nicholas Miell" at Jun 09, 2002 02:36:49 PM
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org

Nicholas Miell writes:
> On Sun, 2002-06-09 at 13:53, Albert D. Cahalan wrote:
>> Nicholas Miell writes:

>>> First of all, some programs (WINE) will actually want
>>> to use the .lnk files, and transparently converting
>>> them to symlinks will complicate that.
>>
>> WINE needs to be able to handle a symlink on ext2, so it can
>> damn well convert back. It's OK to give WINE some hack to get at
>> the content; it's not OK to hack bash to interpret .lnk files.
>
> Why would bash even want to interpret shortcut files?

Some of the shortcut files are symlinks. Of course
this is disgusting, since bash shouldn't have to be
aware of the underlying filesystem type. One would
have to add disgusting hacks to many programs,
including: ln tar mc cpio

> They're a proprietary,
> Windows-only format

...like vfat itself. You might as well argue for ripping
that out and using a userspace solution like mtools.

> Hacking the filesystem to treat something that
> fundamentally is not a symlink as a symlink

Symlinks are implemented, poorly, as .lnk files.
I don't care if you wish it weren't so. Microsoft
doesn't care either.

>>> More importantly, shortcuts are a hell of a lot more complicated than
>>> has been implied. Not only can they point to local files or UNCs (the
>>> \\server\share\path notation), they can also point to any object in the
>>> (Windows) shell's namespace, which includes lots of virtual objects that
>>> don't actually exist on disk.
>>
>> One can live with an occasional broken symlink:
>> "foo" --> "[UNIMPLEMENTED LINK TYPE]"
>
> One can also live with "foo.lnk". (It's much easier and saner, too.)

It's also unusable from common UNIX tools.

>>> Finally, I haven't seen any justification for why symlinks on VFAT are
>>> needed, beyond some vague statements that it's useful when dual booting.
>>> Face it, VFAT isn't a Unix filesystem and introducing ugly hacks to make
>>> it more similar to one will only cause problems in the long run. If you
>>> want symlinks, use a real filesystem or use umsdos on your favorite FAT
>>> filesystem. (Assuming that umsdos still works...).
>>
>> [ insane abuse of VFAT for multi-user systems ]
>
> You're not serious, right?

I'm very serious. The ability to install without partitioning
is important for hesitant new users.

Why not? The system might feel "unclean" to you, but it's
great for converting the Windows users. Not many people
are willing to trash their one-and-only partition, full of
data, to experiment with a new OS. Regular users don't
keep backups. Linux is the only UNIX-like OS that could
do a respectable job of running multi-user on vfat.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/