On Wed, Oct 28, 2009 at 00:52, Yakov Lerner <[email protected]> wrote:

> On Wed, Oct 21, 2009 at 17:13, James Vega <[email protected]> wrote:
>
>>
>> On Wed, Oct 21, 2009 at 10:52 AM, Arve Knudsen <[email protected]>
>> wrote:
>> >
>> > On 21 Okt, 13:58, James Vega <[email protected]> wrote:
>> >> On Wed, Oct 21, 2009 at 02:33:46AM -0700, Arve Knudsen wrote:
>> >> > I have a very annoying problem with the x64 build of Vim 7.2 on
>> >> > Windows 7, for some reason it creates files named "4913" during
>> >> > editing. Is this a bug, or maybe triggered by a problem with my
>> >> > system?
>> >>
>> >> As a quick Google would tell you, Vim creates this file in an attempt
>> to
>> >> verify it can create a file in the directory in which you see the file
>> >> and set the uid/gid.  It's just a temporary file used during the
>> process
>> >> of creating a backup file.
>> >
>> > I did Google it, and found that it could be a problem on network-
>> > filesystems? The problem is that it *isn't* temporary, it persists.
>>
>> Here's the code:
>>
>> 3486                 for (i = 4913; ; i += 123)
>> 3487                 {
>> 3488                     sprintf((char *)gettail(IObuff), "%d", i);
>> 3489                     if (mch_lstat((char *)IObuff, &st) < 0)
>> 3490                         break;
>> 3491                 }
>> 3492                 fd = mch_open((char *)IObuff,
>> 3493
>> O_CREAT|O_WRONLY|O_EXCL|O_NOFOLLOW, perm);
>> 3494                 if (fd < 0)     /* can't write in directory */
>> 3495                     backup_copy = TRUE;
>> 3496                 else
>> 3497                 {
>> 3498 # ifdef UNIX
>> 3499 #  ifdef HAVE_FCHOWN
>> 3500                     ignored = fchown(fd, st_old.st_uid,
>> st_old.st_gid);
>> 3501 #  endif
>> 3502                     if (mch_stat((char *)IObuff, &st) < 0
>> 3503                             || st.st_uid != st_old.st_uid
>> 3504                             || st.st_gid != st_old.st_gid
>> 3505                             || (long)st.st_mode != perm)
>> 3506                         backup_copy = TRUE;
>> 3507 # endif
>> 3508                     /* Close the file before removing it, on
>> MS-Windows we
>> 3509                      * can't delete an open file. */
>> 3510                     close(fd);
>> 3511                     mch_remove(IObuff);
>> 3512                 }
>>
>> If mch_open (line 3492) returns a file descriptor, then we get into
>> the following else which always calls mch_remove on the file (line
>> 3511).
>
>
> Arve, I wonder if changing line 3494 'if( fd < 0 )' to 'if( fd == -1)'
>  fixes the problem ?
> Can you make the change on line 3494, rebuild vim, and see if there is
> change ?
>
> Yakov
>
> PS
> I learned once that on win32, you *must* write
> if(sock == -1) and never if(sock < 0).
> Win32 sockets can be negative.  Yes they really can be.
> msdn specs _open()  as returning  -1 on error, not "negative number".
>
>
I was wrong. _open can't return negative fd.
Maybe moving mch_remove()
after brace 3512 fixed it ?
Maybe win32 _open() has
some race where  it creates the file but then returns -1 ?

--~--~---------~--~----~------------~-------~--~----~
You received this message from the "vim_dev" maillist.
For more information, visit http://www.vim.org/maillist.php
-~----------~----~----~----~------~----~------~--~---

Raspunde prin e-mail lui