In comp.os.linux.advocacy, Mark Kent
<mark.kent@xxxxxxxxxxx>
wrote
on Thu, 5 Jun 2008 23:58:29 +0100
<ll7mh5-sl4.ln1@xxxxxxxxxxxxxxxxxxxxxx>:
> Roy Schestowitz <newsgroups@xxxxxxxxxxxxxxx> espoused:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> ____/ Linonut on Friday 16 May 2008 00:43 : \____
>>
>>> * rbchinchen@xxxxxxxxx peremptorily fired off this memo:
>>>
>>>> Today I was renaming come music videos I was recovering from a backup.
>>>> As most of you would know, doing this is usually a pain because you
>>>> have to play the file, figure out what it is and then close the player
>>>> or play another file so you can edit the file name of the video.
>>>>
>>>> Being an average user I was predisposed to do this through Windows,
>>>> archive on an external FAT32 hdd and have it accessible from both
>>>> Windows and Linux. But today, just to be adventurous, I tried doing it
>>>> through Linux, openGEU to be precise. I found that I could edit the
>>>> file names WHILE watching them, so I could have in one window the
>>>> videos playing and in the other my file manager program renaming the
>>>> files. I cut my time by more than half (just to explain a little
>>>> further, most of the clips have info a few seconds in about artist and
>>>> track).
>>>>
>>>> When I saw this phenomenom I was astounded. I am no expert on the
>>>> internal workings of an operating system, but it appears that Linux
>>>> can access a file even when its name changes, without needing the
>>>> information put back in. I just wanted to know, does anyone know
>>>> whether this is because of the FS I am using (ext3) or is it just the
>>>> way Linux works?
>>>
>>> It's a UNIX feature, copy-on-write. If one app has a file open, and
>>> another app modifies the file in anyway, the modified version becomes a
>>> copy of the original with the new modifications.
>>>
>>> When the old file is closed by the first app, it then goes away.
>>
>> I sometimes delete video/music files while watching/listening to them to save
>> up disk space. They carry on playing.
>>
>
> Well, presumably you don't actually save the space until the file is
> really deleted, ie., once it's been closed?
>
That is correct; the Linux filesystem handling maintains a
use count for each and every inode (including directories).
For files, opening a file increments the usecount; closing
the file decrements it. When a usecount becomes zero,
the kernel deletes the inode and reclaims the disk space,
but only then.
Directory usecounts are at least 2 (parent's directory
entry and the directory's '.' entry), and increment for
each subdirectory (because of '..' in that directory).
It's a very elegant if slightly redundant system; one can
easily move/rename any file because one's not changing that
inode at all, merely moving it within the naming tree.
(If one changes directories the old and new parent
directories' contents may change, but the inode being
moved does not.)
Deleting an open file changes the usecount from 2 to 1,
and the music plays on (if it's a music file being played).
Note that specifying a file on an argument list is not
sufficient; if one does
plaympeg *.mpg
and in another shell
rm *.mpg
plaympeg will probably print a 'file not found' message
after playing and closing (and thereby deleting) the
current file. It might print a bunch of them as it walks
through its argument list.
It is possible for two entries to refer to the same inode,
via a hardlink (ln). Symbolic links (ln -s) do not refer
to inodes, but to relative paths, which means they are
more brittle; however, hard links cannot link to anything
outside of their filesystem (if, say, /usr/sbin/example ->
'../../bin/example' is a symbolic link, no problem, but
if one attempts to use a hardlink and has / both and /usr
mounted, the kernel rejects the attempt).
Hardlinking directories might be possible but gives
headaches, mostly because of inclusion of an ancestor,
creating a loop.
Windows NTFS apparently doesn't do inodes, which means
deleting an open file is very difficult. Symbolic
links are implemented by '.lnk' files and interpreted
by Internet Explorer, but not by the file system.
--
#191, ewill3@xxxxxxxxxxxxx
Useless C/C++ Programming Idea #10239993:
char * f(char *p) {char *q = malloc(strlen(p)); strcpy(q,p); return q; }
** Posted from http://www.teranews.com **
|
|
