4913

The world is more mysterious than I realised.

Before reading on, do you know the mysterious property of 4913?

As regulars here know, I am a Linux user. My favourite editor is one found on every unix machine, namely vi. Well, not the actual original vi, whose movement commands are somewhat cryptic, but the replacement vim (“vi improved”), which does at least use the arrow keys in the way you would expect. (Did I ever tell the story of how I persuaded John Conway to produce a paper for a conference proceedings published in time for the conference?)

I usually use vi from the command line in a terminal. But, possibly because of advancing age causing advancing holes in my memory, I have once or twice recently used the file selector to find the file I am looking for, having forgotten the pathname, then opened a terminal in this directory to use vi. On doing so, I noticed that at the end of the session there was a locked file called 4913 in the directory.

More experimentation showed several curious things. This is not a real file, since it does not show up in a directory listing (which is why I hadn’t spotted it before), and since it doesn’t exist, it can’t be deleted. However, it can be opened with another text editor such as gedit. If you do this, type in a character, and save, then the file takes on a real existence; it is no longer locked, and can be deleted in the usual way. Moreover, if you don’t do this but use vi again, the mysterious 4913 disappears; it seems to be toggled by the use of the editor.

A Google search for the number 4913 led me to a question someone had asked on StackExchange ten years ago. So this mystery has been known for ten years, and nobody, it seems, considered it worth doing anything about it in the intervening time. Well, I suppose that writing a non-existent locked file isn’t really a bug in the programme. But why 4913? I don’t know that!

However, lovers of numbers will no doubt have noticed that 4913 is a perfect cube.

Advertisements

About Peter Cameron

I count all the things that need to be counted.
This entry was posted in Uncategorized and tagged , , , , . Bookmark the permalink.

13 Responses to 4913

  1. Yemon Choi says:

    In the spirit of “Foucault’s Pendulum”, perhaps it was part of the ZIP code or building number of one of the original coders?

  2. Duncan says:

    I never see this 4913 file. According to an answer on stackexchange it’s used when creating a backup copy.

    https://vi.stackexchange.com/a/9380

  3. Dima says:

    It’s probably a bug in locale (or other stuff related to non-ascii terminal I/O) handling; the directory listing uses some of it, as you should see a solid line at the end of the file listing, and 4913 might be an artefact of producing this line.

  4. Dima says:

    In fact, 4913 is one of possible names of temporary files needed and tried by vim to create some sort of lock or something, see
    https://github.com/b4winckler/vim/blob/1f611c1f921bc219b44272f13a298cd8d97aa6f0/src/fileio.c#L3704

  5. Jon Awbrey says:

    (1 + ⓪ + ① + ② + ③ + ④ + ⑤ + ⑥ + ⑦ + ⑧ + ⑨ + Ⓐ + Ⓑ + Ⓒ + Ⓓ + Ⓔ + Ⓕ)³

  6. Jon Awbrey says:

    Also, {4913}_{10} = {1331}_{16}, the 3rd row of Pascal’s Triangle.

  7. I am not sure how reproducible this 4913 is. But here is what happens under Scientific Linux on my desktop machine.
    Edit a new file with vi, save it: nothing. But after that, each edit and save toggles 4913: it appears after the second time, disappears after the third, and so on.

  8. Jan Hubicka says:

    4913 is hard wired into vim. It can use any other name for same purpose, but i guess it had some special meaning for the author.
    /*
    * 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);

    Normally it should remove it immediately after creation…. I have never seen it on Linux but for Windows the removal may fail if antivirus tries to check it for viruses between creation and removal time.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s