Flash content download

Question

I've been wondering something, websites like youtube (pandora does mp4s)

• play their music through a flash player
• while each track is played, they're downloaded to the user's computer, e.g., /tmp/FlashXX***

This allows users to go and move the flv out of that folder for later playback.

However, when the user moves the flv out of the /tmp folder, the player continues to play the music/video quite happily. How does the flash player handle the removal of its file and why doesn't it throw errors from this?

More importantly, why are the flvs downloaded to the user in the first place if the player plays happily without them?

Answer 1

The content keeps playing even after you remove the file from the temp folder because Flash has read the file into memory in order to display it. It's conceptually the same reason as why, if you drag a locally-stored image into a browser, the browser doesn't stop displaying the image if you then delete the file.

As for why the file gets stored, it's simply being cached, like any other file your browser displays, so that if you reload the page, you won't (necessarily) have to reload the media file.

For video there may be caveats to all this, though - for example, if you seek forward or backwards in a video I couldn't swear to whether the video will be played from memory if the cached version has been removed... and I would imagine that there are situations where Flash doesn't keep the entire movie in memory. But as a general case answer things should be as described here.

Answer 2

I assume you're describing behavior on a *nix system?

They might just be watching the file system using something like this, or inotify, or this .NET event. I would be surprised if a modern version of Windows allowed you to move the temporary .flv file, and it would be nuts if flash didn't wig out because of it.

But yeah, my guess is that on your operating system, flash player isn't fazed when the file moves because it receives a handle to the new path in case it needs to read from the file again. What happens if you deliberately change permissions or corrupt or delete the .flv while a long (say, ~ one hour) video is playing?

Answer 3

This actually has nothing to do with caching. Rather, it works due to the way Unix filesystems work. When a file is opened, its inode is read and indicates where the data is located on the disk. When a file is moved or deleted ("unlinked"), the inode is moved to a new location or removed from the directory. However, the data it points to is not invalidated until no reference to that inode exists. In other words, as long as a file remains open, deleting or moving it has no effect on a program reading that file.

This is not how Windows filesystems work, and that is was leads to the common "file is locked" problems when trying to delete files that are in use. (Disclaimer: This may not be true with NTFS, which supports hard links, but I'm pretty sure it was the case on FAT.)

It works so well that sometimes programs will even use a trick to automatically clean up after itself by creating a file and "removing" it right away, while keeping it open. That way, the temporary file can continue to be used until the program is done with it, at which time it automatically "disappears".

By the way, programs that expect to be able to close and reopen a temporary file will get confused if you move them. You can avoid this by making a "copy" using a hard link.

ln /tmp/Fl* .

This command will create copies of the inode referenced by Flash for the temporary file into the current directory. It doesn't actually copy the content of the file, only creates a second reference to the same data on disk. That way when Flash closes, you still have a "pointer" to the data that it released.

I haven't studied this topic in some time and I might have gotten some terminology wrong, so I suggest if you want to understand further, read up on inodes and how hard links work.

From that Wikipedia link:

The process of unlinking dissociates a name from the data on the volume without destroying the associated data. The data are still accessible as long as at least one link that points to it still exists. When the last link is removed, the space is considered free.