tar 'mini'-bug

tar 'mini'-bug

[Gary R Van Sickle]

For a long time tar has been behaving strangely, and I'm just reporting it
since I can't seem to find anybody else that has.  If I 'tar -xjf' a
snapshot overtop of the current cygwin installation on Why2K, I get this,
what I assume is the expected result since cygwin1.dll is being used by tar
and bash:

$ tar -xjf cygwin-inst-20010807.tar.bz2
tar: usr/bin/cygwin1.dll: Cannot open: File exists
tar: Error exit delayed from previous errors

Now when I do the exact same thing on the universally-hated Windows 'ME',
tar simply hangs and must be killed by a CTRL-C.  '--exclude=cygwin1.dll' of
course makes it work fine.

Just wanted to make this a known issue.  Perhaps someday after I've purged
all memory of the "\n / \r\n / \r / CTRL-Z / no CTRL-Z" fiasco from the
collective memory I'll take a look inside and see what's causing this
difference.

Gary R. Van Sickle
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337


--
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/

Re: tar 'mini'-bug

[Gary R Van Sickle]

>On Wed, Aug 08, 2001 at 04:40:28PM -0500, Gary R Van Sickle wrote:
>> Mmmm, I think you're wrong on that.  I believe ME, crappy as it is, gets
>> this one thing right and behaves the same as Why2K in that respect, in
that
>> you can't write to an executable file that's in use by the OS.  I'm not
at a
>
>Excerpt from MSDN:
>
>    Windows 95/98/Me: The DeleteFile function deletes a file even if it
>    is open for normal I/O or as a memory-mapped file. To prevent loss
>    of data, close files before attempting to delete them.
>
>    Windows NT/2000 or later: The DeleteFile function fails if an
>    application attempts to delete a file that is open for normal I/O
>    or as a memory-mapped file.

Jesus Cobble-job Christ.  Just when you think Win9x can't get any worse.  I
suppose one could try a CreateFile() with write access before the delete,
assuming THAT would fail (which is of course a nebulous assumption).  Or
simply wait for the XP forced upgrade to deliver its whole new bag of
oddball behavior in a few months.

Gary R. Van Sickle
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337


--
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/

RE: tar 'mini'-bug

[David Starks-Browning]

On Wednesday 8 Aug 01, Gary R Van Sickle writes:
> > Isn't setup.exe able to upgrade cygwin1.dll in place?
> 
> Not to the snapshots according to the FAQ.  Hang on, let me try it though...
> nope.

You can't use setup.exe to install snapshots, but the FAQ does include
instructions for installing snapshots "manually".  The instructions
carefully avoid using cygwin tar to update cygwin1.dll.  Hope this helps.

Regards,
David
(Cygwin FAQ maintainer)


--
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/

Re: tar 'mini'-bug

[Corinna Vinschen]

On Wed, Aug 08, 2001 at 04:40:28PM -0500, Gary R Van Sickle wrote:
> Mmmm, I think you're wrong on that.  I believe ME, crappy as it is, gets
> this one thing right and behaves the same as Why2K in that respect, in that
> you can't write to an executable file that's in use by the OS.  I'm not at a

Excerpt from MSDN:

    Windows 95/98/Me: The DeleteFile function deletes a file even if it
    is open for normal I/O or as a memory-mapped file. To prevent loss
    of data, close files before attempting to delete them.

    Windows NT/2000 or later: The DeleteFile function fails if an
    application attempts to delete a file that is open for normal I/O
    or as a memory-mapped file.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

--
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/

RE: tar 'mini'-bug

[Gary R Van Sickle]

> Isn't setup.exe able to upgrade cygwin1.dll in place?

Not to the snapshots according to the FAQ.  Hang on, let me try it though...
nope.

> I thought it could.  If so, that's by far your best bet.
>
> This is a Windows behavioral problem, not a cygwin issue.
>
> On the NT family of OS's, you can't overwrite a DLL that's
> currently in use.  It's locked.  That's why you get that
> message.
>
> On Windows ME (a.k.a. DOS 9 or is it DOS 10?  I forget.) there
> are no such strict file locking semantics, so in my understanding
> the behavior is somewhat undefined if you try to overwrite a DLL
> on a FAT32 partition when it's currently in use.  I've never tried
> it.  But I would say it's not a wise thing to do ;->
>

Mmmm, I think you're wrong on that.  I believe ME, crappy as it is, gets
this one thing right and behaves the same as Why2K in that respect, in that
you can't write to an executable file that's in use by the OS.  I'm not at a
ME system right now though so I can't verify that.

> But you can take advantage of the fact that Win32 first
> attempts to load a DLL from the directory where the .exe
> resides before scanning the PATH.  Copy tar.exe and
> cygwin1.dll to some other location, maybe c:\temp.  Then
> run
>
> bash$ /cygwin/c/temp/tar xvf <filename>
>
> to get around this problem.  Then go delete your temporary
> cygwin1.dll since you're not supposed to let multiples of
> them reside on your system at the same time ;->
>

Well right, I can (and do) easily get around it, but my point is that I
don't think tar should be hanging on ME if it's not able to write to a file.

Gary R. Van Sickle
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337


--
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/

RE: tar 'mini'-bug

[Troy Noble]

Isn't setup.exe able to upgrade cygwin1.dll in place?
I thought it could.  If so, that's by far your best bet.

This is a Windows behavioral problem, not a cygwin issue.

On the NT family of OS's, you can't overwrite a DLL that's
currently in use.  It's locked.  That's why you get that
message.

On Windows ME (a.k.a. DOS 9 or is it DOS 10?  I forget.) there
are no such strict file locking semantics, so in my understanding
the behavior is somewhat undefined if you try to overwrite a DLL
on a FAT32 partition when it's currently in use.  I've never tried
it.  But I would say it's not a wise thing to do ;->

But you can take advantage of the fact that Win32 first
attempts to load a DLL from the directory where the .exe
resides before scanning the PATH.  Copy tar.exe and
cygwin1.dll to some other location, maybe c:\temp.  Then
run

bash$ /cygwin/c/temp/tar xvf <filename>

to get around this problem.  Then go delete your temporary
cygwin1.dll since you're not supposed to let multiples of
them reside on your system at the same time ;->

But if setup.exe will work, use that instead.

Troy

-----Original Message-----
From: Gary R Van Sickle [ mailto:tiberius@braemarinc.com ]
Sent: Wednesday, August 08, 2001 1:01 PM
To: Cygwin Mailing List (E-mail)
Subject: tar 'mini'-bug


For a long time tar has been behaving strangely, and I'm just reporting it
since I can't seem to find anybody else that has.  If I 'tar -xjf' a
snapshot overtop of the current cygwin installation on Why2K, I get this,
what I assume is the expected result since cygwin1.dll is being used by tar
and bash:

$ tar -xjf cygwin-inst-20010807.tar.bz2
tar: usr/bin/cygwin1.dll: Cannot open: File exists
tar: Error exit delayed from previous errors

Now when I do the exact same thing on the universally-hated Windows 'ME',
tar simply hangs and must be killed by a CTRL-C.  '--exclude=cygwin1.dll' of
course makes it work fine.

Just wanted to make this a known issue.  Perhaps someday after I've purged
all memory of the "\n / \r\n / \r / CTRL-Z / no CTRL-Z" fiasco from the
collective memory I'll take a look inside and see what's causing this
difference.

Gary R. Van Sickle
Braemar Inc.
11481 Rupp Dr.
Burnsville, MN 55337


--
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/

--
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/