root delete file when other user open it

[guixingyi]

I am wondering that if root delete file meanwhile normal user opens and edits it, what's will happen to I/O.

If you try this produce this issue that you can find no error occurred after changed file and saved by normal user.


besides, when multiple users open and edit same file, one user changed and saved and closed file and then second user changed something and save, what's will happen to I/O.

some guys know the principle, or give the link of web search

appreciate!:e

 

[graudeejs]

if file is deleted while it's opened, it can still be accessed by program who keeps it open, but you won't see it with ls.
When file is closed it will be removed completely

 

[bsddaemon]

From the FreeBSD FAQ:

When a program is using a file, and you delete the file, the file is not really removed from the file system until the program stops using it. The file is immediately deleted from the directory listing, however. You can see this easily enough with a program such as more. Assume you have a file large enough that its presence affects the output of du and df. (Since disks can be so large today, this might be a very large file!) If you delete this file while using more on it, more does not immediately choke and complain that it cannot view the file. The entry is simply removed from the directory so no other program or user can access it. du shows that it is gone -- it has walked the directory tree and the file is not listed. df shows that it is still there, as the file system knows that more is still using that space. Once you end the more session, du and df will agree.

http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/disks.html#DU-VS-DF

 

[anemos]

When file is closed it will be removed completely

Actually, from rm(1) 's source code it seems that the file is unlink(2)ed. Also, I noticed that if I open and edit a file with, say, vim and at the same time I delete it, if I ask vim to save the file it'll save it again. If I just quit vim and then ls, the file will be lost. Again, the file itself is not completely deleted.
Maybe a developer could shed some light on the very intrinsic mechanisms.

 

[graudeejs]

That's what i mean. Files are never deleted actually Unless -P key is specified. The data itself always stays on HDD for as long as something else is written over. vim will modify data, because it has pointer (or whatever should i call it) to it, but once vim is closed, that pointer is lost, however data can be recovered until you overwrite them.

 

[trasz@]

Ok, here is the explanation of this. First, root has nothing to do with this. It doesn't matter if the file is deleted by root or some other user. Second: In UNIX, there is a difference between removing a file, so that it's no longer visible in ls(1) output, and removing contents of the file from the disk. When you remove the file (using rm(1)), it disappears from the directory. However, if some application keeps the file open, then it still has access to its contents, and it's undamaged on the disk. Contents of the file will be removed after the application closes it.

So: If you open a file in vim, then remove the file using rm(1), file contents will be lost in the moment you quit vim without saving. If you choose to save the file you just deleted, vim will create the file with the same name as before, and write the contents there.

One situation where this is important is disk space reclamation. For example, you might notice that /var/log/messages takes way too much disk space. If you remove it, the disk usage won't drop. It will drop after you restart syslogd. That because the logfile contents are still stored on the disk, until the syslog closes the (now removed) log file.

 

[guixingyi]

Thank you all guys!

appreciate!

 

[dada]

Thank you all guys!

appreciate!

If you can read Chinese, here's an article describing this behavior.

http://blog.urdada.net/2007/11/20/65/

Test program:

#include <stdio.h>
#include <fcntl.h>
int main()
{
        int     fd, i;
        char    cmd[32], buf[1024];
        memset( buf, 0, 1024);
        snprintf(cmd,sizeof(cmd),"df .");
 
        printf("==> open file for write and delete it ...\n");
        fd = open( "test-file.log", O_CREAT|O_WRONLY|O_TRUNC );
        unlink("test-file.log");
        system(cmd);
 
        printf("\n==> write 100MB to file ...\n");
        for( i = 0 ; i < 1000*100 ; i++ )
                write( fd, buf, 1024);
        system(cmd);
 
        printf("\n==> close file ...\n");
        close(fd);
        system(cmd);
}

Output:

==> open file for write and delete it ...
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/ad8s1d 144520482 [color="Blue"]28011428[/color] 104947416    21%    /home

==> write 100MB to file ...
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/ad8s1d 144520482 [color="Blue"]28111508[/color] 104847336    21%    /home

==> close file ...
Filesystem  1K-blocks     Used     Avail Capacity  Mounted on
/dev/ad8s1d 144520482 [color="Blue"]28011428[/color] 104947416    21%    /home

 

[lme@]

So: If you open a file in vim, then remove the file using rm(1), file contents will be lost in the moment you quit vim without saving. If you choose to save the file you just deleted, vim will create the file with the same name as before, and write the contents there.

What if the system crashes at this point (not that FreeBSD can crash at all )? I guess the file is lost then? vim keeps a backupfile of it but other editors don't, so let's assume there is none.

 

[Mel_Flynn]

Never got an vi.recover message? This is why vi needs /var mounted.

Some editors do use tmpfile(3) or simply work in-memory and when enough users whine then implement an autobackup scheme.

 

[richardpl]

So: If you open a file in vim, then remove the file using rm(1), file contents will be lost in the moment you quit vim without saving. If you choose to save the file you just deleted, vim will create the file with the same name as before, and write the contents there.

Vim is so user friendly that user will be notified that file has gone.

 

[liamjfoy]

So: If you open a file in vim, then remove the file using rm(1), file contents will be lost in the moment you quit vim without saving. If you choose to save the file you just deleted, vim will create the file with the same name as before, and write the contents there.

Euhmm, file content lost? Are you sure? Surely vim just can't open it again using the filename(since you did a rm) ? The comment sounds like the contents on the disk would be lost. I'm not sure this is true (unless vim is doing something it shouldnt be doing imo). Maybe I'm wrong...

 

[graudeejs]

Euhmm, file content lost? Are you sure? Surely vim just can't open it again using the filename(since you did a rm) ? The comment sounds like the contents on the disk would be lost. I'm not sure this is true. Maybe I'm wrong...

File content ain't lost.
It can't be lost.

Even after you rewrite over file (this is different case, but just wanted to mention), it is still possible to recover original old data. It's just question, how much you can pay for it, and who will recover it.

 

[liamjfoy]

File content ain't lost.
It can't be lost.

Even after you rewrite over file (this is different case, but just wanted to mention), it is still possible to recover original old data. It's just question, how much you can pay for it, and who will recover it.

Exactly so I was right. The contents aren't actually lost - all that happens is vim can still point to it via FD. So after you close vim it forgets where the file is (because you did a rm, thus no filename to 'open').

No contents are lost - they're still on the disk (unless you did rm overwrite).

 

[liamjfoy]

What if the system crashes at this point (not that FreeBSD can crash at all )? I guess the file is lost then? vim keeps a backupfile of it but other editors don't, so let's assume there is none.

At the point of vim being open and the file rm'd? Nothing would happen. You just can't restart the system and do vim filename. But the contents of the file will remain on disk (unless you did rm overwrite).

 

[liamjfoy]

File content ain't lost.
It can't be lost.

Even after you rewrite over file (this is different case, but just wanted to mention), it is still possible to recover original old data. It's just question, how much you can pay for it, and who will recover it.

Ah - that *CAN* depend

 

[trasz@]

OK, a little clarification is in order. By writing "file content will be lost", I mean it will be impossible for applications to get to it in any way other than by bypassing the filesystem and reading the disk device directly.

Basically, it's all about "file detached from the directory structure" and "file actually removed".