Question about files under Linux ext3 partition

[oog]

I was seeding a file through bittorrent using the bittornado curses client. I wasn't thinking and deleted the file with "rm" from another window. I didn't kill the bittornado client though, and it looks like it's still seeding.

Is this because the bittorrent client cached the file in memory? Is it a feature of the file system on an ext3 partition that as long as a process is using the file, it'll stay around even though it's not accessible to me any longer? Is there another explanation?

As soon as I'm done seeding enough to satisfy my conscience, I'll quit the bittorrent client.

 

[drag]

Well I just think it's one of those happy accidents.

when you delete a file it doesn't wipe it off of the harddrive. It just deletes the pointer to the file. This pointer is called a 'link' or a 'hardlink'. For instance you can have a file with several 'hardlinks', which when you look at it from the user's percpective you have a file with a number of filenames (as apposed to "softlinks" which are pointers that you can treat like file/directory names, but are just used for shortcuts). But normally you have one.


So when you delete a file, you simply remove the pointer in it's parent directory. Then it's 'deleted'. The data is still there, but it's just unobtainable now.

probably what happens is that the program has it cached in memory, or it still knows the address on the disk to access the file, or something.

This sort of thing would be avoided in Windows because of Window's file lock features. Remember: "you can't delete this file because it's still in use" type things.

My guess it'll probably keep working until the OS needs to write a file to disk and by dumb luck just happens to overwrite your old file. I donno what will happen then.. depends on the app... maybe it will just crash, or maybe just notice the file is missing, or just lock up, or maybe start sending corrupt data.

Who knows. Maybe the app doesn't even use the file you think it does. Maybe it keeps copies of the download in /tmp directory and then assembles them and puts them in your final location peice by peice.

All this is just guesswork. I don't know what is realy going on.

If your curious you can play around with it. Check out lsof and strace.

lsof is ls open files. It'll show the files currently in use by the system and which application is using them.


Also strace will show system calls and such outputted by a application.

go:
ps aux |less
and find the pid number of your application.

Then go:
strace -p thepidnumber -o logfile

then kill it after a few seconds of logging. Then go thru the logfile output and see if you can figure out what it is doing.

I don't understand most of the ouput of strace, but you can kind of guess at it and figure it out that way.

Also nice tool for debugging application problems like permissions issues or missing files.

To use lsof go like

lsof |grep btdownload

 

[oog]

I'll have to do the testing another time. I guess there are three theories: the file is cached in memory, the file is still accessible by the program even though it's not accessible to through the parent directory (though it could get overwritten), or the file was copied somewhere else by the program.

The reason I can't test it now is that I have neither lsof nor strace on this (gentoo) machine. I realize I could easily emerge them, but I'm done seeding this particular file. I'll try it another time.

Thanks for the reply, and good choice of avatars.

 

[drag]

Yep yep.

Also I just remembered that btdownloadcurses is a python program (I think), you could always look at the source code.

oh, and you NEED strace and lsof. They are some good stuff.