Re: vim prompt E484: Can't open file
在 2018年4月6日星期五 UTC+8下午10:38:03，Christian Brabandt写道：
> On Do, 05 Apr 2018, brucekan...@gmail.com wrote:
>
> > 在 2018年4月3日星期二 UTC+8下午6:35:57，Christian Brabandt写道：
> > > On Di, 03 Apr 2018, brucekan...@gmail.com wrote:
> > >
> > > > I'm using VIM 8.0 and set the option: "set
> > > > cscopequickfix=s-,c-,d-,i-,t-,e-"
> > > > vim will prompt "E484: Can't open file /tmp/vx/n" occasionally if
> > > > I'm not root user.
> > > >
> > > > when set above option, vim will generate a temp directory under /tmp, I
> > > > found the temp direcoty was deleted every time when the fault was
> > > > occurred.
> > > >
> > > > after checking source code, the suspecious place is in function:
> > > > vim_tempname
> > > >
> > > > if (vim_tempdir != NULL)
> > > > {
> > > > /* There is no need to check if the file exists, because we own the
> > > > * directory and nobody else creates a file in it. */
> > > > sprintf((char *)itmp, "%s%ld", vim_tempdir, temp_count++);
> > > > return vim_strsave(itmp);
> > > > }
> > > >
> > > > if the vim_tempdir is deleted by unknown operation/process, then vim
> > > > will fault due to it not checking this temp directory before writing
> > > > it, maybe we need to check vim_tempdir here, if it's not accessable, we
> > > > build another temp directory.
> > >
> > > Do you have any tmp cleanup packages installed that may remove such
> > > things? Try to disable it.
> > >
> > > I have proposed a similar patch several years ago, but it was found to
> > > work around the real problem that /tmp should not be cleaned randomly,
> > > so it wasn't included.
> > >
> > >
> > > Best,
> > > Christian
> > > --
> > > Wußten Sie schon...
> > > ... daß der Walfisch, das größte lebende Säugetier, alle anderen
> > > Säugetiere an Größe übertrifft?
> >
> > Hi Christian,
> > Thanks for you response, I haven't deep investigated which
> > process/operation delete that temp directory(this fault only appear when I
> > am a normal user, when I am root, everything is ok), there is another
> > scenario: vim user may use vim on a shared server, they can't disable
> > cleanup process run in background or prevent other user delete that temp
> > diretory, so they can't guarantee that temp direcoty is always there, my
> > opinion is vim should not depend it's stability on external environment
> > especially public directory, there may happen something out of vim user's
> > control.
>
> True, but some people believe that the system is broken, if it silently
> deletes directories below /tmp. After all, that's what /tmp is for. It
> may only be deleted on reboot.
>
> Best,
> Christian
>
> --
> Was wir der Natur antun, tun wir uns selbst an.
> -- Sprichwort der Mapuche-Indianer (Chile)
Hi Christian,
I traced the temp directory by "auditd", I found it's deleted by
"gnome-settings-daemon" due to I have set cleanup temp files automatically for
protect privacy in gnome-shell.
now it's clear, gnome-shell cleanup the temp directory for protect privacy, the
temp directory lost cause vim fault, it also can explain why everything is ok
when I'm root in terminal(gnome-shell belong to normal user can't delete the
temp directory which belong to root)
from technology perspective, it's no problem, /tmp is for temp files
from product or high level perspective: I'm a linux user, I use vim, and I also
need my system protect my privacy, after all, I use other applications too, for
current solution, I have to disable cleanup program which protect my privacy if
I want vim run well.
so, should vim improve itself ? Thank you.
BR,
Bruce.
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: vim prompt E484: Can't open file
在 2018年4月3日星期二 UTC+8下午6:35:57，Christian Brabandt写道：
> On Di, 03 Apr 2018, brucekan...@gmail.com wrote:
>
> > I'm using VIM 8.0 and set the option: "set cscopequickfix=s-,c-,d-,i-,t-,e-"
> > vim will prompt "E484: Can't open file /tmp/vx/n" occasionally if I'm
> > not root user.
> >
> > when set above option, vim will generate a temp directory under /tmp, I
> > found the temp direcoty was deleted every time when the fault was occurred.
> >
> > after checking source code, the suspecious place is in function:
> > vim_tempname
> >
> > if (vim_tempdir != NULL)
> > {
> > /* There is no need to check if the file exists, because we own the
> > * directory and nobody else creates a file in it. */
> > sprintf((char *)itmp, "%s%ld", vim_tempdir, temp_count++);
> > return vim_strsave(itmp);
> > }
> >
> > if the vim_tempdir is deleted by unknown operation/process, then vim will
> > fault due to it not checking this temp directory before writing it, maybe
> > we need to check vim_tempdir here, if it's not accessable, we build another
> > temp directory.
>
> Do you have any tmp cleanup packages installed that may remove such
> things? Try to disable it.
>
> I have proposed a similar patch several years ago, but it was found to
> work around the real problem that /tmp should not be cleaned randomly,
> so it wasn't included.
>
>
> Best,
> Christian
> --
> Wußten Sie schon...
> ... daß der Walfisch, das größte lebende Säugetier, alle anderen
> Säugetiere an Größe übertrifft?
Hi Christian,
Thanks for you response, I haven't deep investigated which process/operation
delete that temp directory(this fault only appear when I am a normal user, when
I am root, everything is ok), there is another scenario: vim user may use vim
on a shared server, they can't disable cleanup process run in background or
prevent other user delete that temp diretory, so they can't guarantee that temp
direcoty is always there, my opinion is vim should not depend it's stability on
external environment especially public directory, there may happen something
out of vim user's control.
so may be check that path is a better solution if it won't introduces any side
effect, another workaround is add a option to specify path of temp directory
for user themself, eg. set tmpdir = ~/xxx, then temp directory will be build in
this directory, like: ~/xxx/vnNqlrH
BR,
Bruce.
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
vim prompt E484: Can't open file
I'm using VIM 8.0 and set the option: "set cscopequickfix=s-,c-,d-,i-,t-,e-"
vim will prompt "E484: Can't open file /tmp/vx/n" occasionally if I'm not
root user.
when set above option, vim will generate a temp directory under /tmp, I found
the temp direcoty was deleted every time when the fault was occurred.
after checking source code, the suspecious place is in function: vim_tempname
if (vim_tempdir != NULL)
{
/* There is no need to check if the file exists, because we own the
* directory and nobody else creates a file in it. */
sprintf((char *)itmp, "%s%ld", vim_tempdir, temp_count++);
return vim_strsave(itmp);
}
if the vim_tempdir is deleted by unknown operation/process, then vim will fault
due to it not checking this temp directory before writing it, maybe we need to
check vim_tempdir here, if it's not accessable, we build another temp directory.
--
--
You received this message from the "vim_dev" 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_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
