This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: New symlinks.


> -----Original Message-----
> From: Christopher Faylor [mailto:cgf@redhat.com]
> Sent: Thursday, March 01, 2001 1:18 AM
> To: cygwin@cygwin.com
> Subject: Re: New symlinks.

	<skipped>

> 
> >> The bottom line is I don't care a fig about what is "correct".  I'm
> >> concerned about surprising people.  I'm not concerned 
> about exposing
> >the
> >> ".lnk" for power users if it causes confusion for the vast 
> majority of
> >> people who are not power users.  I'm concerned about increasing
> >mailing
> >> list traffic by 10% when it could be avoided.
> >
> >Ok, so when you get 100's of emails. "I made a symlink on my samba
> >share, then I went to delete it via bash on the samba server and I
> >couldn't find the file", you'll be _glad_ there is no sign 
> within cygwin
> >that a .lnk was created.
> 
> Those kinds of emails are actually pretty rare.  And, 
> actually, we could
> work around this problem now by just checking if a Cygwin 
> symbolic link
> file is read-only, just like we do for .lnk files.

In fact I think the problem is not this one; it's rather:

on my cygwin machine, on a samba share:
	cygwin$ ln -s foo bar

later on, on th esamba server:
	linux$ find . -name 'foo' | xargs rm

the back on cygwin:
	cygwin$ ls foo
	foo

Hey it still exists; I deleted it on the samba share without any error! (of
course, find on the samba server do NOT match foo with foo.lnk) This used to
work and I don't understand what's happening...

The ONLY way out of this is to give the user SOME way to see that foo is in
fact foo.lnk...

> 
> >If you don't show somewhere in cygwin that it is a .lnk file may well
> >end up surprising them anyway.
> 
> I don't know why.  If you can do all of your manipulation of the file
> without the extension then there is no reason to care about the
> extension.

Problem is that cygwin is NOT an OS; it's a layer in another world... so you
can't hide .lnk in ALL cases...

> 
> >> >My vote: we expose the.lnk at at least one place in the 
> interface. We
> >> >also make it interoperate seamlessly for scripts/batch files etc.
> >>
> >> I'm not sure what "interoperate seamlessly" means.  It 
> would be nice
> >> if people would try what Corinna has implemented before offering
> >opinions.
> >> Or, maybe you have done this and are just reiterating Corinna's
> >> implementation.
> >>
> >By interopreate seamlessly I mean, don't break shell scripts 
> or programs
> >that use lnks. (Obviously thats the goal, what I what trying 
> to say is
> >'show the .lnk somewhere, don't break anything to achieve that).
> 
> Um, yeah.  That's a pretty obvious goal.  Unfortunately, it definitely
> means not exposing the .lnk extension (unless *possibly* it 
> is explicitly
> asked for).

I think that's what Corinna implement, and it's quite satisfactory.

Regards,

	Bernard

PS: Note that I'm NOT arguing against Corinna's opinion that "ls -l foo.lnk"
should show the symlink, but against other's opinions that it should answer
"file not found". I can't check as I just want to emphasize what I think it
should be (or continue to be).

--------------------------------------------
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:	+33 (0) 1 47 68 80 80
Fax:	+33 (0) 1 47 88 97 85
e-mail:	dautrevaux@microprocess.com
		b.dautrevaux@usa.net
-------------------------------------------- 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]