> I thank you all for your help, but I really can't use your
> recommendations without screwing up something else on my system. I
> have a script which runs automatically on system startup which
> immediately references this ntfs drive, so I must have this drive
> automount on startup like my internal HD, or the script will fail. It
> runs for several hours, during which I can't unmount and remount the
> drive.
Nobody said nothing about mount or umount nothing manually. You just
need to change the mount options in your /etc/fstab file.
Try something like this:
/dev/sdb1 /media/500gb ntfs-3g
rw,user,auto,uid=<username>,gid=<groupname> 0 0
...changing <username> and <groupname> with your user and primary
group names (primary group name is tipically the same as username --in
fact, in Ubuntu, Debian and many other distros this is the default--).
Umounting and remounting (with 'mount -a') is only to make changes to
take effect without rebooting.
But, in fact, them will take effect next time you reboot regardless
you manually umount/remount or not.
>
> The initial mount command assigns the drive to ROOT:ROOT with rwx
> permissions for all users. These cannot be changed with chown, chmod,
> chgrp as explained at
> http://ubuntu.swerdna.org/ubuntfs.html
[...]
This is **exactly** what I said in my first email in this thread:
«Ownership and permissions are set only in the mount command.»
...they are set only in the mount command, but THEY ARE SET anyway.
They defaults to root:root because root is the user who executes the
mount command and no other thing is specified in fstab. Then root is a
reasonable default option, but you can change this acording to your
needings.
> I appreciate that one can get vim to write to this drive by having it
> use a different linux command to do so, and am already doing that.
> But I often forget to use it because my vim shutdown script
> automatically writes out any altered buffers; but then it fails if it
> tries to write to this ntfs drive. The only feasible solution for me
> is to elaborate my shutdown script to choose the appropriate write
> procedure for each buffer.
...or discover what is causing this problem and fix it ;-)
> I think this is a bug in vim. The ownership of the file should not be
> an issue, only the permissions, which are as they should be.
I suspect not.
Execute vim with '-u /dev/null' (I think there is better way, but I
don't remember it now) to avoid processing your .vimrc and try to edit
and save some file in your NTFS filesystem.
If it fail again, try to temporary remove all your plugins (If you
have any) by renaming plugins directory.
If I'm in truth, then you only need to play enabling/disabling
settings in your .vimrc or plugins to determine which is causing the
problem.
If it continues failing, then it will seem a vim issue, but I think
this will not occour because, as you said, vim doesn't need to change
ownership or permissions to save a file. But some plugins or mappings
may need it.
> This is
> the standard adhered to by all other apps except, as far as I know,
> only vim.
Vim must use operating system services to write files (there is no
other way to do it for non privileged users in linux --and
definitively there is no other right way to do it--).
This services are the same for all programs. SURE your vim is trying
to do something else. The questions are WHAT and WHY.
Regards.
--
Joan Miquel Torres__________________________________
Linux Registered User #164872
http://www.mallorcaweb.net/joanmiquel
BULMA: http://bulma.net http://breu.bulma.net/?l2301
--
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
No comments:
Post a Comment