Re: /var partition seems locked or read only

[berenger.morel@neutralite.org]

Le 28.07.2014 22:36, Andrei POPESCU a écrit :
> On Lu, 28 iul 14, 11:24:31, berenger.morel@neutralite.org wrote:
> > Le 27.07.2014 01:42, PaulNM a écrit :
> >
> > >Inodes are files/folders, files/folders are inodes. (1-to-1)  
> > Anything
> > >that has a bunch of files/folders will use a bunch of inodes. Same
> > >number in fact.
> >
> > Hum... is it accurate?
> > Files can use more than one inode, with ln
>
> Are you talking about hard links? As far as I understand (but I'm 
> sure
> someone will correct me if I'm wrong) the file itself is always just 
> one
> inode, but there are one or more directory entries (links) pointing 
> to
> it. If you remove all of them the file is deleted.
>
> > Folders can not, AFAIK, since
> > symlinks are simply pointers to inodes (which are themselves 
> > pointers --with
> > reference counter I guess, std::shared_ptr in c++11?-- to data).
> > I'm simply asking, I might be completely wrong or inaccurate...
>
> Symbolic links, a.k.a. soft links, a.k.a. "symlinks" are files
> themselves (i.e. each using one inode) that contain a pointer to one 
> of
> the directory entries of another file or directory.

That was what I thought, yesterday before trying to ask those 
questions. While asking them, I did some quick research, because I had 
doubt.
What I learned is that the kind of symlinks you speak about, is slow 
(for various reasons. I've discovered that on the French version of this 
article: 
http://en.wikipedia.org/wiki/Symlink#Storage_of_symbolic_links), and 
that there are now another kind of symlinks, much faster, which are not 
files since they do not use clusters: all informations are contained in 
the inode. So, less disk space, and it seems that it avoid keeping open 
more than one inode, which was a problem of the file approach.

> $ rm testfile
> $ cat testsl
> cat: testsl: No such file or directory
>
> (the error message is a bit misleading)

From what I have learn recently, it seems that misleading messages are 
common when playing with filesystems outside the classic uses.

> $ file testsl
> testsl: broken symbolic link to `testfile'

> This should also explain why hard links only work on the same 
> filesystem
> while symbolic links also work across file systems and why you can
> delete a file if and only if you have write permissions for the
> *directory* containing it :)
>
> Kind regards,
> Andrei