> Why would bash even want to interpret shortcut files? They're a proprietary,
> Windows-only format that have no real use beyond icons in the Start Menu
> or on the desktop. Hacking the filesystem to treat something that
> fundamentally is not a symlink as a symlink is even stupider than
> hacking bash to do the same thing.
vfat is a proprietary windows-only format. Why are we supporting it?
If we do then lets make it as easy to use as possible including symlinks.
> 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.
> > > 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...).
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.
-
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/