Bug 427711

Summary:	vim creates test file named 4913
Product:	[Fedora] Fedora	Reporter:	JW <ohtmvyyn>
Component:	vim	Assignee:	Karsten Hopp <karsten>
Status:	CLOSED UPSTREAM	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	high	Docs Contact:
Priority:	low
Version:	8	Keywords:	Reopened
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2008-10-30 12:36:55 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description JW 2008-01-07 01:02:07 UTC

Description of problem:
vim creates a poorly-named test file "4913"

Version-Release number of selected component (if applicable):
vim-7.1.135-1.fc8

How reproducible:
Always

Steps to Reproduce:
1. inotifywatch -m somedir
2. vim somedir/file
3.
  
Actual results:
Amongst the various temporary files that vim creates (.file.swp, .file.swpx,
file~ etc) it also creates one named "4913".

Expected results:
If vim wants to create a test file it should make it a hidden one.

Additional info:
It would be better if vim didn't create a test file, but if it really has to
then it would be far better to create one named ".4913" or whatever so that the
myriad junk files created can be easily identified and excluded from any
monitoring (inotify) and also which is less likely to interfere with another
application that might try to create a file named 4913 during the short time
during which vim has created such a file.  vim's action can break an application
which needs to create a file named 4913.  If vim created a file .4913 then much
less likely to break another application.  But even better why doesn't vim
create something based on the edited files name?

Comment 1 Karsten Hopp 2008-02-25 16:35:55 UTC

I cannnot reproduce this with a recent version, can you please try again with at
least vim-7.1-211 (F8-updates) or newer(rawhide) ?

Comment 2 JW 2008-02-25 21:55:43 UTC

(In reply to comment #1)
> I cannnot reproduce this with a recent version, can you please try again with at
> least vim-7.1-211 (F8-updates) or newer(rawhide) ?

Well maybe you need to try harder?

Suggested approaches for those who don't try very hard:

1. grep -r 4913 vim71
2. inotifywait ... testdir; vim testdir/newfile
3. ask somebody else who can be bothered

Please, don't just dismiss bug reports without trying a little harder.
This bug still exists in vim-7.1.233-2

Comment 3 Karsten Hopp 2008-02-26 13:12:01 UTC

Are you using a modified vimrc ? If so, please attach.
This isn't reproducable with an unmodified vimrc or vim -u NONE -U NONE :

[vim] >inotifywait -m /home/devel/karsten/src/extras/devel/vim/1/
Setting up watches.
Watches established.
/home/devel/karsten/src/extras/devel/vim/1/ CREATE .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ OPEN .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ CREATE .testfile.swpx
/home/devel/karsten/src/extras/devel/vim/1/ OPEN .testfile.swpx
/home/devel/karsten/src/extras/devel/vim/1/ CLOSE_WRITE,CLOSE .testfile.swpx
/home/devel/karsten/src/extras/devel/vim/1/ DELETE .testfile.swpx
/home/devel/karsten/src/extras/devel/vim/1/ CLOSE_WRITE,CLOSE .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ DELETE .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ CREATE .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ OPEN .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ MODIFY .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ MODIFY .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ MODIFY .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ CLOSE_WRITE,CLOSE .testfile.swp
/home/devel/karsten/src/extras/devel/vim/1/ DELETE .testfile.swp

re:3.  how about the upstream maintainers at vim-dev ? If this is such a
big issue, I'm quite sure other distributions might be interested in having it
fixed as well.

Comment 4 JW 2008-02-26 13:27:05 UTC

But wait ... were you creating a new file?

No ... you were just editing an existing file.
I can see that quite clearly.

Why don't you read the code?  Is quite clearly creates a file called 4913 before
creating a NEW file.

You cannot take a purely random approach to bug fixing.  You need to apply a
more methodical and interested approach.

Comment 5 Karsten Hopp 2008-02-26 13:46:49 UTC

I don't like your tone at all, you're >< this close to getting on my ignore list.

The above was just the last one of several attempts, creating a new file doesn't
change anything:
>cd vim
/home/devel/karsten/src/extras/devel/vim
hagen:[vim] >rm -rf 1
hagen:[vim] >mkdir 1
hagen:[vim] >inotifywait -m 1/
Setting up watches.
Watches established.
1/ CREATE .testfile.swp
1/ OPEN .testfile.swp
1/ CREATE .testfile.swpx
1/ OPEN .testfile.swpx
1/ CLOSE_WRITE,CLOSE .testfile.swpx
1/ DELETE .testfile.swpx
1/ CLOSE_WRITE,CLOSE .testfile.swp
1/ DELETE .testfile.swp
1/ CREATE .testfile.swp
1/ OPEN .testfile.swp
1/ MODIFY .testfile.swp
1/ CREATE testfile
1/ OPEN testfile
1/ CLOSE_WRITE,CLOSE testfile
1/ CLOSE_WRITE,CLOSE .testfile.swp
1/ DELETE .testfile.swp

You didn't answer my first question in comment #3 and you most probably didn't
care to report it where it belongs, right ? So why should I care ?

Comment 6 JW 2008-02-26 22:40:02 UTC

> So why should I care ?

It does create a file 4913.  There must be a bug in the way you are doing your test.

Why don't you at least read the source?
That might tell you that the particular vim settings are significant (eg.
writebackup, backup, patchmode).

Why should I have to guide you step by step through what should be a relatively
simple procedure?

Here it is (in fileio.c line 3343):

                /*
                 * Check if we can create a file and set the owner/group to
                 * the ones from the original file.
                 * First find a file name that doesn't exist yet (use some
                 * arbitrary numbers).
                 */
                STRCPY(IObuff, fname);
                for (i = 4913; ; i += 123)
                {
                    sprintf((char *)gettail(IObuff), "%d", i);
                    if (mch_lstat((char *)IObuff, &st) < 0)
                        break;
                }
                fd = mch_open((char *)IObuff,
                                    O_CREAT|O_WRONLY|O_EXCL|O_NOFOLLOW, perm);