public inbox for cygwin@cygwin.com
 help / color / mirror / Atom feed
* RE: unlink() problem
@ 2001-08-08 12:49 John Wiersba
  2001-08-08 12:58 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 6+ messages in thread
From: John Wiersba @ 2001-08-08 12:49 UTC (permalink / raw)
  To: 'Larry Hall (RFK Partners, Inc)', 'cygwin'

Thanks for your reply, Larry.  Unfortunately, this is a bad bug since the
simple perl script below removes the original file (whoops!) since it
assumes that if you have permission to unlink the original file, then you
have permission to create a new file of the same name (I believe this is
always true on unix).  The net result is that you lose your data.

I can't think of anyway around it except to know that you can't do inplace
editing on cygwin.

-- John Wiersba

> -----Original Message-----
> From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> Sent: Tuesday, July 31, 2001 6:59 PM
> To: John Wiersba; 'cygwin'
> Subject: Re: unlink() problem
> 
> 
> At 06:22 PM 7/31/2001, John Wiersba wrote:
> >I'm having a problem with unlink().  I've scanned the FAQ 
> and searched some
> >in the newsgroup archives for information about the 
> following problem.  I
> >did find a post (see
> > http://sources.redhat.com/ml/cygwin/2001-05/msg01095.html ) 
> but no apparent
> >resolution.
> >
> >$ touch asdf
> >$ perl -i -pe 1 asdf
> >Can't do inplace edit on asdf: Permission denied.
> >
> >What perl is doing is equivalent to:
> >
> >$ perl -e '
> >    open A, "< asdf" or die "one $!";  # open asdf for read
> >    unlink "asdf";
> >    open B, "> asdf" or die "two $!";  # open asdf for write
> >    while (<A>) { print B }            # copy from A to B
> >'
> >two Permission denied at -e line 4.
> >
> >The problem:  after the unlink(), I can't open the same 
> filename for write
> >as I can on unix.  If I pause the program after unlinking 
> asdf, it is still
> >there and can be seen by ls, but can't be read by ls -l.  
> >
> >Is there a workaround for this behavior?  Is it considered a 
> bug or is it
> >just a quirk of the cygwin implementation of trying to implement unix
> >filesystem semantics on top of windows?
> 
> 
> The latter.  This has been quite a day for this issue!  This is the 
> third time it came up.  Perhaps this qualifies as an FAQ now! ;-)
> 
> See my previous posts about this subject from earlier in the day:
> 
> http://www.cygwin.com/ml/cygwin/2001-07/msg01797.html
> http://www.cygwin.com/ml/cygwin/2001-07/msg01774.html
> 
> There's also a related FAQ, although the message it mentions doesn't
> seem to pop up anymore, which gives insight into the underlying 
> implementation.  See:
> 
> http://www.cygwin.com/faq/faq_4.html#SEC57
> 
> Of course, the code is the "last word" on this subject in terms of the
> actual implementation.
> 
> 
> 
> 
> 
> 
> 
> Larry Hall                              lhall@rfk.com
> RFK Partners, Inc.                      http://www.rfk.com
> 118 Washington Street                   (508) 893-9779 - RFK Office
> Holliston, MA 01746                     (508) 893-9889 - FAX
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: unlink() problem
  2001-08-08 12:49 unlink() problem John Wiersba
@ 2001-08-08 12:58 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 0 replies; 6+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-08-08 12:58 UTC (permalink / raw)
  To: John Wiersba, 'cygwin'

At 03:47 PM 8/8/2001, John Wiersba wrote:
>Thanks for your reply, Larry.  Unfortunately, this is a bad bug since the
>simple perl script below removes the original file (whoops!) since it
>assumes that if you have permission to unlink the original file, then you
>have permission to create a new file of the same name (I believe this is
>always true on unix).  The net result is that you lose your data.
>
>I can't think of anyway around it except to know that you can't do inplace
>editing on cygwin.


Right.  I suppose if one could queue up the file creation as well, 
this might help.  Still it ain't UNIX semantics by a long shot!


> > -----Original Message-----
> > From: Larry Hall (RFK Partners, Inc) [ mailto:lhall@rfk.com ]
> > Sent: Tuesday, July 31, 2001 6:59 PM
> > To: John Wiersba; 'cygwin'
> > Subject: Re: unlink() problem
> > 
> > 
> > At 06:22 PM 7/31/2001, John Wiersba wrote:
> > >I'm having a problem with unlink().  I've scanned the FAQ 
> > and searched some
> > >in the newsgroup archives for information about the 
> > following problem.  I
> > >did find a post (see
> > > http://sources.redhat.com/ml/cygwin/2001-05/msg01095.html ) 
> > but no apparent
> > >resolution.
> > >
> > >$ touch asdf
> > >$ perl -i -pe 1 asdf
> > >Can't do inplace edit on asdf: Permission denied.
> > >
> > >What perl is doing is equivalent to:
> > >
> > >$ perl -e '
> > >    open A, "< asdf" or die "one $!";  # open asdf for read
> > >    unlink "asdf";
> > >    open B, "> asdf" or die "two $!";  # open asdf for write
> > >    while (<A>) { print B }            # copy from A to B
> > >'
> > >two Permission denied at -e line 4.
> > >
> > >The problem:  after the unlink(), I can't open the same 
> > filename for write
> > >as I can on unix.  If I pause the program after unlinking 
> > asdf, it is still
> > >there and can be seen by ls, but can't be read by ls -l.  
> > >
> > >Is there a workaround for this behavior?  Is it considered a 
> > bug or is it
> > >just a quirk of the cygwin implementation of trying to implement unix
> > >filesystem semantics on top of windows?
> > 
> > 
> > The latter.  This has been quite a day for this issue!  This is the 
> > third time it came up.  Perhaps this qualifies as an FAQ now! ;-)
> > 
> > See my previous posts about this subject from earlier in the day:
> > 
> > http://www.cygwin.com/ml/cygwin/2001-07/msg01797.html
> > http://www.cygwin.com/ml/cygwin/2001-07/msg01774.html
> > 
> > There's also a related FAQ, although the message it mentions doesn't
> > seem to pop up anymore, which gives insight into the underlying 
> > implementation.  See:
> > 
> > http://www.cygwin.com/faq/faq_4.html#SEC57
> > 
> > Of course, the code is the "last word" on this subject in terms of the
> > actual implementation.
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > Larry Hall                              lhall@rfk.com
> > RFK Partners, Inc.                      http://www.rfk.com
> > 118 Washington Street                   (508) 893-9779 - RFK Office
> > Holliston, MA 01746                     (508) 893-9889 - FAX
> > 


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: unlink() problem
@ 2001-08-09  9:31 Robinow, David
  0 siblings, 0 replies; 6+ messages in thread
From: Robinow, David @ 2001-08-09  9:31 UTC (permalink / raw)
  To: 'cygwin'

> -----Original Message-----
> From: Robinow, David [ mailto:drobinow@dayton.adroit.com ]
> Sent: Wednesday, August 08, 2001 4:37 PM
> Subject: RE: unlink() problem
> > ...  The net result is that you lose your data.
> > 
> > I can't think of anyway around it except to know that you 
> can't do inplace
> > editing on cygwin.
> > 
> > -- John Wiersba
>  
> > > >$ touch asdf
> > > >$ perl -i -pe 1 asdf
> > > >Can't do inplace edit on asdf: Permission denied.
>  But using ActiveState perl,
> 
>       D:\home>perl -i -pe 1 asdf
>       Can't do inplace edit without backup.
>  
>  and the file's not clobbered.
>  Time to look at the perl source code.
  The following seems to do the trick.

--- perl-5.6.1-1/doio.c	Thu Aug  9 11:34:16 2001
+++ perl-5.6.1-1/doio.c~	Sun Dec 17 23:46:49 2000
@@ -655,7 +655,7 @@
 #endif
 		}
 		else {
-#if !defined(DOSISH) && !defined(AMIGAOS) && !defined(__CYGWIN__)
+#if !defined(DOSISH) && !defined(AMIGAOS)
 #  ifndef VMS  /* Don't delete; use automatic file versioning */
 		    if (UNLINK(PL_oldname) < 0) {
 		        if (ckWARN_d(WARN_INPLACE))	

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: unlink() problem
@ 2001-08-08 13:36 Robinow, David
  0 siblings, 0 replies; 6+ messages in thread
From: Robinow, David @ 2001-08-08 13:36 UTC (permalink / raw)
  To: 'cygwin'

> From: John Wiersba [ mailto:John.Wiersba@medstat.com ]
> Subject: RE: unlink() problem
> Thanks for your reply, Larry.  Unfortunately, this is a bad bug since the
> simple perl script below removes the original file (whoops!) since it
> assumes that if you have permission to unlink the original file, then you
> have permission to create a new file of the same name (I believe this is
> always true on unix).  The net result is that you lose your data.
> 
> I can't think of anyway around it except to know that you can't do inplace
> editing on cygwin.
> 
> -- John Wiersba
 
> > >$ touch asdf
> > >$ perl -i -pe 1 asdf
> > >Can't do inplace edit on asdf: Permission denied.
 But using ActiveState perl,

      D:\home>perl -i -pe 1 asdf
      Can't do inplace edit without backup.
 
 and the file's not clobbered.
 Time to look at the perl source code.

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: unlink() problem
  2001-07-31 15:24 John Wiersba
@ 2001-07-31 16:00 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 0 replies; 6+ messages in thread
From: Larry Hall (RFK Partners, Inc) @ 2001-07-31 16:00 UTC (permalink / raw)
  To: John Wiersba, 'cygwin'

At 06:22 PM 7/31/2001, John Wiersba wrote:
>I'm having a problem with unlink().  I've scanned the FAQ and searched some
>in the newsgroup archives for information about the following problem.  I
>did find a post (see
> http://sources.redhat.com/ml/cygwin/2001-05/msg01095.html ) but no apparent
>resolution.
>
>$ touch asdf
>$ perl -i -pe 1 asdf
>Can't do inplace edit on asdf: Permission denied.
>
>What perl is doing is equivalent to:
>
>$ perl -e '
>    open A, "< asdf" or die "one $!";  # open asdf for read
>    unlink "asdf";
>    open B, "> asdf" or die "two $!";  # open asdf for write
>    while (<A>) { print B }            # copy from A to B
>'
>two Permission denied at -e line 4.
>
>The problem:  after the unlink(), I can't open the same filename for write
>as I can on unix.  If I pause the program after unlinking asdf, it is still
>there and can be seen by ls, but can't be read by ls -l.  
>
>Is there a workaround for this behavior?  Is it considered a bug or is it
>just a quirk of the cygwin implementation of trying to implement unix
>filesystem semantics on top of windows?


The latter.  This has been quite a day for this issue!  This is the 
third time it came up.  Perhaps this qualifies as an FAQ now! ;-)

See my previous posts about this subject from earlier in the day:

http://www.cygwin.com/ml/cygwin/2001-07/msg01797.html
http://www.cygwin.com/ml/cygwin/2001-07/msg01774.html

There's also a related FAQ, although the message it mentions doesn't
seem to pop up anymore, which gives insight into the underlying 
implementation.  See:

http://www.cygwin.com/faq/faq_4.html#SEC57

Of course, the code is the "last word" on this subject in terms of the
actual implementation.







Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 6+ messages in thread

* unlink() problem
@ 2001-07-31 15:24 John Wiersba
  2001-07-31 16:00 ` Larry Hall (RFK Partners, Inc)
  0 siblings, 1 reply; 6+ messages in thread
From: John Wiersba @ 2001-07-31 15:24 UTC (permalink / raw)
  To: 'cygwin'

I'm having a problem with unlink().  I've scanned the FAQ and searched some
in the newsgroup archives for information about the following problem.  I
did find a post (see
http://sources.redhat.com/ml/cygwin/2001-05/msg01095.html ) but no apparent
resolution.

$ touch asdf
$ perl -i -pe 1 asdf
Can't do inplace edit on asdf: Permission denied.

What perl is doing is equivalent to:

$ perl -e '
   open A, "< asdf" or die "one $!";  # open asdf for read
   unlink "asdf";
   open B, "> asdf" or die "two $!";  # open asdf for write
   while (<A>) { print B }            # copy from A to B
'
two Permission denied at -e line 4.

The problem:  after the unlink(), I can't open the same filename for write
as I can on unix.  If I pause the program after unlinking asdf, it is still
there and can be seen by ls, but can't be read by ls -l.  

Is there a workaround for this behavior?  Is it considered a bug or is it
just a quirk of the cygwin implementation of trying to implement unix
filesystem semantics on top of windows?

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2001-08-09  9:31 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2001-08-08 12:49 unlink() problem John Wiersba
2001-08-08 12:58 ` Larry Hall (RFK Partners, Inc)
  -- strict thread matches above, loose matches on Subject: below --
2001-08-09  9:31 Robinow, David
2001-08-08 13:36 Robinow, David
2001-07-31 15:24 John Wiersba
2001-07-31 16:00 ` Larry Hall (RFK Partners, Inc)

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).