Re: vfat patch for shortcut display as symlinks for 2.4.18

[Joseph Mathewson <joe@mathewson.co.uk>]

In message "Re: vfat patch for shortcut display as symlinks for 2.4.18",
<<christoph@lameter.com>> wrote:

> > One can also live with "foo.lnk". (It's much easier and
> saner, too.)
>
> No one cannot untar a source tarball with symlinks in a vfat fs without
> the patch. We cannot live with foo.lnk. Its insane not to carry over the
> semantics as much as possible.

Does the proposed patch give full symlink support or does it just read .lnk
files?  Most source tarballs will not have .lnk files in them, they will have
symlinks.  Would tar create the .lnk files if it was extracting to vfat?  If the
patch gives symlink support in some other way than .lnk files, why can't we just
use that and not meddle with reading the .lnk files to allow Linux to run in a
vfat partition.

> vfat is the only fs that can be shared between microsoft oses and linux.
> umsdos mangles filenames and does other ugly things. umsdos is an example
> of what not to do with a fs. umsdos is a hack. vfat+symlinks is the
> completion of an implementation.

This is why I think MS will (and are) killing FAT 32 as quickly as they can (the
last properly understood MS filesystem...).  To really entice users from Windows
in the future, this kind of patch is going to have to work on NTFS, not FAT.
Now that the NT codebase is the "home" codebase as well (with the advent of XP),
NTFS is going to take massive inroads into FAT's market share.  And there have
been rumours for a while that MS SQL Server is going to form the basis of the
next MS filesystem.

Joe.

+-------------------------------------------------+
| Joseph Mathewson <joe@mathewson.co.uk>          |
+-------------------------------------------------+