Bug 427711 - vim creates test file named 4913
vim creates test file named 4913
Product: Fedora
Classification: Fedora
Component: vim (Show other bugs)
All Linux
low Severity high
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2008-01-06 20:02 EST by JW
Modified: 2008-10-30 08:36 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-10-30 08:36:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description JW 2008-01-06 20:02:07 EST
Description of problem:
vim creates a poorly-named test file "4913"

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. inotifywatch -m somedir
2. vim somedir/file
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 11:35:55 EST
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 16:55:43 EST
(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 08:12:01 EST
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@vim.org ? 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 08:27:05 EST
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 08:46:49 EST
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
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.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 17:40:02 EST
> 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)
                fd = mch_open((char *)IObuff,
                                    O_CREAT|O_WRONLY|O_EXCL|O_NOFOLLOW, perm);

Note You need to log in before you can comment on or make changes to this bug.