E-CARD from Your Fine Art E-cards service ************ (0414664716)

2004-02-12 Thread E-CardsFromStValentine

===
===

Greetings!

Your Fine Art E-cards service has sent you an E-Card -- a virtual postcard 
from 
Gallery-A.RU. You can pickup your card at the Gallery-A.RU website. 

=}}} If your e-mail is hot-link enabled click here:
 http://www.gallery-a.ru/ecards/?ticket=02220020220041113
   

=}}} You may also point your web browser to: http://www.gallery-
a.ru/ecards/
 then enter your E-Card ticket number: 
 02220020220041113

Your E-Card will be saved for pickup for 15 days from the date of
sending (Wed, Feb 12, 2004 20:13:02 MSK(+0300)).  

Enjoy your E-Card! 

===
=== 



Re: [PATCH] Thread safe stdio

2004-02-12 Thread Thomas Pfaff
Christopher Faylor wrote:
On Wed, Feb 11, 2004 at 11:08:57AM +0100, Thomas Pfaff wrote:

The __sinit call must be done after malloc is initialized, otherwise the 
mutex creation will fail.


I am not comfortable with this part of the patch.  I moved the __sinit
call where I did for a reason.  It needed to be called earlier in the
process.  I'm also somewhat uncomfortable with using malloc for this
purpose in general.  It seems like a heavyweight solution to something
that could be solved with either a muto or a critical section.

Please keep in mind that:

- There does not exist only one mutex, every file has its own that is 
created on fopen and destroyed when it is closed.

- I do not call malloc directly, it is called as part of the mutex creation.

- Every mutex that is associated with an open file must be fork save, it 
has to be recreated after a fork.

- _flock_t can not be a CRITICAL_SECTION nor class muto. You can not 
implement newlibs _LOCK_INIT macro with this types, i have not seen 
something like a CRITICAL_SECTION_INITIALIZER or a MUTO_INITIALIZER.


[Patch] rename

2004-02-12 Thread Pierre A. Humblet
MoveFile on XP Home Edition returns error ERROR_ACCESS_DENIED when
the destination file already exists on a remote disk located
on a Win98 machine.

This leads to the same problem with rename() as that reported in
http://www.cygwin.com/ml/cygwin-patches/2000-q2/msg00069.html

The patch simply removes the test on the error when
MoveFileEx is available. I have read the long history of rename()
and the only reported trouble with MoveFileEx is the deletion
of the file when source name == destination name, except for case.
So removing the test should be OK.
 
I have kept the test on 9X to avoid spurious DeleteFile calls
on the destination.

Pierre

2004-02-12  Pierre Humblet [EMAIL PROTECTED]

* syscalls.cc (rename): Do not test the MoveFile error code
where MoveFileEx exists.

 

Index: syscalls.cc
===
RCS file: /cvs/src/src/winsup/cygwin/syscalls.cc,v
retrieving revision 1.319
diff -u -p -r1.319 syscalls.cc
--- syscalls.cc 9 Feb 2004 04:04:24 -   1.319
+++ syscalls.cc 12 Feb 2004 03:28:41 -
@@ -1314,20 +1314,18 @@ rename (const char *oldpath, const char 
(lnk_suffix = strrchr (real_new.get_win32 (), '.')))
  *lnk_suffix = '\0';
 
-  if (!MoveFile (real_old, real_new))
-res = -1;
-
-  if (res == 0 || (GetLastError () != ERROR_ALREADY_EXISTS
-   GetLastError () != ERROR_FILE_EXISTS))
+  if (MoveFile (real_old, real_new))
 goto done;
 
+  res = -1;
   if (wincap.has_move_file_ex ())
 {
   if (MoveFileEx (real_old.get_win32 (), real_new.get_win32 (),
  MOVEFILE_REPLACE_EXISTING))
res = 0;
 }
-  else
+  else if (GetLastError () == ERROR_ALREADY_EXISTS
+  || GetLastError () == ERROR_FILE_EXISTS)
 {
   syscall_printf (try win95 hack);
   for (int i = 0; i  2; i++)