Bug 73216 - vfat support for cygwin-style symlinks
vfat support for cygwin-style symlinks
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Arjan van de Ven
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2002-08-31 17:50 EDT by Stig Hackvan
Modified: 2008-08-01 12:22 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-30 11:39:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stig Hackvan 2002-08-31 17:50:41 EDT
Description of Problem:

I'm caught between worlds and it's incredibly painful.  I "need" to be able to
access the same files from windows and linux.  I also "need" unix filesystem
semantics because I think unix.  I submit to redhat's marketing sensibilities
that my "needs" are on the critical path for organizations that could be
adopting linux in a piecemeal fashion but do not because it's too painful. 
other markets are dual-boot users (that's me) and cross-platform-developers
(could be me...why don't you get me an interview?)...

I used to love umsdos filesystem support but that got tossed out when vfat and
long filenames came around.  seems like a real waste to me because umsdos
filesystems needed a bit of synchronization with the underlying fat16 filesystem
but provided the TREMENDOUS ADDED VALUE of full support fo unix filesystem
semantics....  including symlinks and linux uids and whatnot.

now i'm trying to make a dual-boot system that gives me filesystem consistency
between winme/cygwin and linux.  it seems that cygwin treats read-only .lnk
files as symlinks (there's GPL source code available for inspection) but linux
does not.  The vfat support does not sufficiently embrace-and-extend win32
filesystem semantics...  cygwin does better, and umsdos did best.  cygwin and
linux-vfat don't even agree on upper & lower case mapping...

umsdos _was_ roughly speaking, a good solution but it's seemingly been dormant
since 1998 and none of the major vendors ship the umsdos-tools package so it's
effectively been dumped...along with anyone who depended upon it.

Expected Results:

i expect that the linux kernel, cygwin, and samba will all adopt a uniform
method of mapping unix filesystem behavior onto win32 filesystems to ease
migration for those caught between the two worlds.

   1. support the same hack for symlinks that is supported by cygwin
      (i think it's .lnk files that are marked read-only)

      1.a. export this hack to samba so that <unix - samba - windows - cygwin>
           "does the right thing where possible" (samba follows symlinks 

   2. adjust default vfat support mount flags to provide the best results on
         cp -a <unix-dir-tree> <vfat-volume>
         diff -r <unix-dir-tree> <vfat-dir-tree>
      (a common problem is that short filenames get mapped wrong CVS != cvs)

   3. update umsdos to incorporate vfat support and hack it into cygwin and
      samba (samba would auto-generate) the umsdos-ish meta-data file as an
      "upgrade" to whatever downgraded directory information it just served 
      up for SMB

1 is high-utility low-hanging fruit
2 is a potential testing hassle but also of HVLH potential
3 is DWIM nirvana for the interdimensional traveller 
  (with the SMOP addition of linux software suspend aka hibernation...
  i've seen patches in FOLK)

-- stig
Comment 1 Bugzilla owner 2004-09-30 11:39:53 EDT
Thanks for the bug report. However, Red Hat no longer maintains this version of
the product. Please upgrade to the latest version and open a new bug if the problem

The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, 
and if you believe this bug is interesting to them, please report the problem in
the bug tracker at: http://bugzilla.fedora.us/

Note You need to log in before you can comment on or make changes to this bug.