Prev: mount(8) followed by umount(8) fails
Next: how to automatically run a script as long as an input file is available
From: Barry Margolin on 12 Mar 2010 16:13 In article <930abafa-010e-41cf-8cf5-eb8d0ed0a43d(a)g10g2000yqh.googlegroups.com>, Francis Moreau <francis.moro(a)gmail.com> wrote: > On Mar 12, 3:10�am, Barry Margolin <bar...(a)alum.mit.edu> wrote: > > In article > > <74384b7d-fac6-48bf-9da3-86894ecc5...(a)z11g2000yqz.googlegroups.com>, > > �Francis Moreau <francis.m...(a)gmail.com> wrote: > > > > > But I'm not trying to access the content of the directory (hence not > > > trying to access to the remote data), I'm just try to stat the > > > directory .gvfs on which something is mounted (that's why I pass '-ld' > > > switches to ls(1)) > > > > Stat accesses the mounted directory, not the underlying mount point. > > > > So are there any ways to stats the underlying mount point ? Not that I know of. Once you mount something, the original mount point is totally hidden. I recall SunOS 4.x had a bug in this regard. A frequent problem was using pwd when the original mount point had restrictive permissions. -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Seebs on 12 Mar 2010 17:45 On 2010-03-12, Barry Margolin <barmar(a)alum.mit.edu> wrote: > In article ><930abafa-010e-41cf-8cf5-eb8d0ed0a43d(a)g10g2000yqh.googlegroups.com>, > Francis Moreau <francis.moro(a)gmail.com> wrote: >> So are there any ways to stats the underlying mount point ? > Not that I know of. Once you mount something, the original mount point > is totally hidden. Almost. If you NFS export a filesystem, and that filesystem contains a mount point, you can't see the mount point (only the filesystem mounted over it) on the server, but a client mounting the filesystem can see the mount point, but not the thing mounted on it. Er, that's hard to follow. /a filesystem /a/b another filesystem If I export /a to a client machine, it can see the underlying directory /a/b which is the mount point, because it can't follow my NFS mount. -s -- Copyright 2010, all wrongs reversed. Peter Seebach / usenet-nospam(a)seebs.net http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
From: Barry Margolin on 12 Mar 2010 18:06 In article <slrnhplh18.5bc.usenet-nospam(a)guild.seebs.net>, Seebs <usenet-nospam(a)seebs.net> wrote: > On 2010-03-12, Barry Margolin <barmar(a)alum.mit.edu> wrote: > > In article > ><930abafa-010e-41cf-8cf5-eb8d0ed0a43d(a)g10g2000yqh.googlegroups.com>, > > Francis Moreau <francis.moro(a)gmail.com> wrote: > >> So are there any ways to stats the underlying mount point ? > > > Not that I know of. Once you mount something, the original mount point > > is totally hidden. > > Almost. > > If you NFS export a filesystem, and that filesystem contains a mount > point, you can't see the mount point (only the filesystem mounted over > it) on the server, but a client mounting the filesystem can see the mount > point, but not the thing mounted on it. True, because NFS mounts are not exported (unless you're using a user-space NFS server, since its view of the local filesystem incorporates all the mounts). -- Barry Margolin, barmar(a)alum.mit.edu Arlington, MA *** PLEASE post questions in newsgroups, not directly to me *** *** PLEASE don't copy me on replies, I'll read them in the group ***
From: Alan Curry on 12 Mar 2010 23:34 In article <barmar-F25A20.16132412032010(a)nothing.attdns.com>, Barry Margolin <barmar(a)alum.mit.edu> wrote: |In article |<930abafa-010e-41cf-8cf5-eb8d0ed0a43d(a)g10g2000yqh.googlegroups.com>, | Francis Moreau <francis.moro(a)gmail.com> wrote: |> So are there any ways to stats the underlying mount point ? | |Not that I know of. Once you mount something, the original mount point |is totally hidden. If you happened to have a process with a cwd in the covered-up area before the mount, all cwd-based references from that process will continue to use the old directory. Also any pre-existing directory file descriptors referring to directories that are covered up can still be used for fchdir() and openat(). I hoped to demonstrate that recent Linux allows you to unshare(CLONE_NEWNS) and then unmount in the new namespace to get at the underlying directory without unmounting it in the global namespace, but the test showed that it doesn't actually work. -- Alan Curry
From: Casper H.S. Dik on 13 Mar 2010 06:16 Barry Margolin <barmar(a)alum.mit.edu> writes: >I recall SunOS 4.x had a bug in this regard. A frequent problem was >using pwd when the original mount point had restrictive permissions. Also true in Solaris 2+; I think it was recently fixed. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth.
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 5 Prev: mount(8) followed by umount(8) fails Next: how to automatically run a script as long as an input file is available |