Thursday, July 17, 2014

Re: Re: Problem with vimdiff and file name resolution

On 2014-07-11, Christian Brabandt wrote:
> Am 2014-07-11 01:54, schrieb Gary Johnson:
> >On the other hand, a file system such as we're using for backups
> >seems pretty unusual, and equal inode numbers over network file
> >systems is also pretty rare. Is this problem worth fixing? Would a
> >patch even be considered? Or should I just resort to workarounds
> >for the few times I have to recover part of a file?
>
> FWIW: In my opinion, vimdiff should just work[TM], so I would like to
> have your fix included. Because if one ever stumbles over your issue,
> it's not easy to understand why it happens (if one even notices, that
> the bug really happened rather than thinking, "Oh those files must be
> the
> same, if vimdiff doesn't show me a differenc...")

I thought it should "just work", too, and would be worth the effort
to fix. However, as I thought more about my initial solution, I
realized that it wouldn't work in all cases and would just trade off
one weird behavior for another.

As Jeff Fisher explained (thanks, Jeff), the NetApp filer takes
liberties with the Linux file system model and doesn't give the user
a means to uniquely identify files by device number and inode
number. I think the fault here clearly lies with NetApp and not
with Vim.

I often use ranger and the RangerChooser command to browse for files
within Vim. I now have a fix for the RangerChooser command that
works around this problem.

I thought that I could use the BufReadCmd event to create a plugin
that would work around this problem when opening a file directly
from Vim, but no luck. It appears that as soon as Vim sees a file
name, it notes its inode number, even if it never opens the file,
and uses that inode number to optimize file accesses. That's been a
bit frustrating. I don't know whether or not that optimization is
over-zealous and could be improved for the purpose of working around
this issue with an autocommand. My feeling is that Bram knew what
he was doing when he wrote that part of the code and that I would
have to know a lot more than I do about Vim to try to improve that
without breaking something, all to fix a problem that is not really
Vim's.

Others have proposed reasonable workarounds that are good enough for
my purposes, so I think I'll live with those.

Thanks everyone for your comments. It's been an education.

Regards,
Gary

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

No comments: