GNU bug report logs - #25930
optimize mv for multiple bind mounts

Previous Next

Package: coreutils;

Reported by: Ruediger Meier <sweet_f_a <at> gmx.de>

Date: Thu, 2 Mar 2017 09:52:01 UTC

Severity: normal

Done: Assaf Gordon <assafgordon <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: L A Walsh <coreutils <at> tlinx.org>
To: Bernhard Voelker <mail <at> bernhard-voelker.de>
Cc: sweet_f_a <at> gmx.de, Sven Joachim <svenjoac <at> gmx.de>, 25930 <at> debbugs.gnu.org
Subject: bug#25930: optimize mv for multiple bind mounts
Date: Thu, 02 Mar 2017 18:24:36 -0800

Bernhard Voelker wrote:
> On 03/02/2017 10:16 PM, L A Walsh wrote:
>>     Anyone know why Linux doesn't do detection by device vs.
>> by mount point?  Both pieces of info have their use, but for rename
>> seems that 'by device' would be optimal.
> 
> quick guess: because not only the device matters.  What if e.g. the
> other bind mount is read-only?
---
Not "cleanly" supported.  mount man page:

  Note  that  the filesystem mount options will remain the same as
  those on the original mount point,  and  cannot  be  changed  by
  passing  the  -o  option  along  with --bind/--rbind.  The mount
  options can be changed by a separate remount command, for  exam-
  ple:

         mount --bind olddir newdir
         mount -o remount,ro newdir

  Note  that  the behavior of the remount operation depends on the
  /etc/mtab file.  The first command stores the 'bind' flag in the
  /etc/mtab  file  and  the second command reads the flag from the
  file.  If you have a system without the /etc/mtab file or if you
  explicitly  define  source  and  target  for the remount command
  (then mount(8) does not read /etc/mtab), then you  have  to  use
  the  bind  flag  (or  option)  for the remount command too.  For
  example:

         mount --bind olddir newdir
         mount -o remount,ro,bind olddir newdir

  Note that remount,ro,bind will  create  a  read-only  mountpoint
  (VFS  entry),  but the original filesystem superblock will still
  be writable, meaning that the olddir will be writable,  but  the
  newdir will be read-only.

----
	It's a bit bothersome that the behavior of the remount
is dependent on existence of /etc/mtab, contents and mount order.


	Interestingly, though, on Windows, I haven't found 
any way of mounting a file system "Read-Only", so maybe that's
not something Windows normally has to worry about in moving files.





This bug report was last modified 6 years and 210 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.