public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
From: "Simon Liesenfeld via cygwin" <cygwin@cygwin.com>
To: cygwin@cygwin.com
Subject: Re: symbolic links on Paragon Linux File systems
Date: Mon, 17 Dec 2018 19:22:00 -0000	[thread overview]
Message-ID: <768216656.5669803.1545072652503@mail.yahoo.com> (raw)
In-Reply-To: <20181217165741.GB28727@calimero.vinschen.de>

 Hi Corinna,
since you answered your own questionsI can better understand my own stupidity.I have created now a hard and a soft link with a native linux,then I booted Windows, started the paragon driver,then cygwin  programs as well as any dos program perfectly 
understood the links.
Even if cygwin were able to understand its own links on paragon volumes,they would not be understood when running the volume by linux again.That does not make sense.
May be there is a command line option from paragonto create links.

Thank you so much Corinna.


    On Monday, December 17, 2018, 5:57:43 PM GMT+1, Corinna Vinschen <corinna-cygwin@cygwin.com> wrote:  
 
 On Dec 17 10:34, Corinna Vinschen wrote:
> On Dec 17 08:11, Simon Liesenfeld via cygwin wrote:
> > Hi all
> > 
> > There is a commercial ext3-4 file system driver for windowsLinux File
> > Systems für Windows | Paragon Softwarewhich enable Windows to read an
> > write on native ext3-4 volumes.In General cygwin works perfectly on
> > such volumes,even named pipes work,
> > but Cygwin programs do not interprete those links correctly,which are
> > created on such volumes.whilst symbolic links on native NTFS drives
> > referring files on such volumeswork perfectly.
> > $pwd/cygdrive/e
> > 
> > $ echo hallo > source
> > 
> > $ ln -s source sl
> > 
> > $ cat sl
> > !<symlink>▒▒source
> 
> Yes, we can't do that without special knowledge of the FS.  The default
> symlinks on Cygwin are only evaluated correctly if the DOS SYSTEM
> attribute is set.  The ext4 driver can't do that, obviously.
> 
> Are the native symlinks on an ext4 FS converted to NTFS symlinks
> on the fly by the driver?  Are they visible as symlinks in Windows
> or Cygwin?
> 
> If so, you could try setting the environment variable CYGWIN to contain
> "winsymlinks:native".  This creates native Windows symlinks rather than
> the special Cygwin POSIX symlinks.  If the driver is handling this
> correctly, it should transparently convert them to ext4 symlinks and
> they should just work.

Answering my own questions:

No, the driver does not handle symlinks gracefully *at all*.

- Existing symlinks on the FS are handled as if they are simple files.
  They are in no way identifiable as symlinks by any Windows client.
  They supposedly only contain the name of the symlink target, which is
  an arbitrary string.  No symlink marker or anything.

- DOS file attributes don't work, so we can't use Cygwin's symlink
  handling, not even by utilizing Windows shortcuts instead of Cygwin
  symlinks.

- Windows native symlinks and transparent conversion to and from ext4
  symlinks is not supported.

- No ACL handling, not even to fake basic POSIX permissions, so we can't
  change the permissions at all.

I don't think it's worth to go to great length supporting Cygwin
symlinks on this FS.  They won't be recognized by your Linux
installation as symlinks anyway and we'd have to perform excessively
slow checks just to recognize them.

As a sidenote, the OSS project Ext2Fsd handles symlinks transparently
via standard Windows functions.  With "CYGWIN=winsymlinks:native" you
can generate real ext4 symlinks transparently.  Even the good old Cygwin
symlink works on Cygwin without programmatic intervention, albeit those
won't be recognized as symlinks by Linux of course.  Unfortunately
Ext2Fsd didn't learn to handle ext4 with the 64bit FS option set yet.
64bit is default for quite some time.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer  
--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

  parent reply	other threads:[~2018-12-17 18:50 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1823593702.5343751.1545034298027.ref@mail.yahoo.com>
2018-12-17  8:11 ` Simon Liesenfeld via cygwin
2018-12-17  9:34   ` Corinna Vinschen
2018-12-17  9:41     ` Corinna Vinschen
2018-12-17 18:45     ` Corinna Vinschen
2018-12-17 18:47       ` Stefan Baur
2018-12-17 18:50         ` Stefan Baur
2018-12-17 19:22       ` Simon Liesenfeld via cygwin [this message]
2018-12-17 19:38         ` Corinna Vinschen
2018-12-17 20:50           ` Simon Liesenfeld via cygwin
2018-12-17 11:35   ` Andrey Repin
2018-12-17 12:04     ` Simon Liesenfeld via cygwin
2018-12-17 12:17       ` Corinna Vinschen
     [not found]       ` <1283756633.5566453.1545061591859@mail.yahoo.com>
2018-12-17 16:35         ` Simon Liesenfeld via cygwin
2018-12-17 16:57           ` Simon Liesenfeld via cygwin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=768216656.5669803.1545072652503@mail.yahoo.com \
    --to=cygwin@cygwin.com \
    --cc=surgeonde@yahoo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).