Re: [AVFS] Problems with fork, Questions about avfs

> I have several questions regarding avfs and I hope to find some answers 
> here. I want to use AVFS for my filemanager 
> (www.boomerangsworld.de/worker). I already tried to use the VFS from MC 
> but as it is not thread safe it is not an option. There are some other 
> VFS but I think avfs is the system which best fits my needs.
> I recently checked out the avfs CVS code and found the shared library. I 
> already use it and it works fine so far. However, I have a few questions 
> and hints.
> First of all I miss some functions. I don't know if the avfs project 
> want to implement the fopen/fread/fclose... function class but this is 
> not a real problem. But there is no virt_remove function. I know it is 
> only a wrapper for unlink/rmdir but according to the man-page the remove 
> function is mentioned in ANSI C, POSIX and other standards so it is 
> perhaps a good idea to implement it.

It's easy to implement:

int virt_remove(const char *path)
{
	struct stat buf;
	virt_stat(path, &buf);
	if (S_ISDIR(buf.st_mode))
		return virt_rmdir(path);
	else
		return virt_unlink(path);
}

I'm sure I havent thought of everything, but it shouldn't be much more
complex.

> A real problem is the init()/destroy() stuff. AVFS is thread safe but 
> not fork safe. In the MC VFS code there are the functions vfs_init and 
> vfs_shut which need to be called by the programmer. AVFS takes care of 
> this itself which is a good thing but it cause problems when forking. If 
> a forked child quits, the destroy function is called which will delete 
> the temporary directory (/tmp/.avfs...) The original process thinks this 
> directory still exists and the VFS does not work properly anymore. I 
> workaround this problem for my filemanager by using _exit for the forked 
> childs but I think there should be a possibility to prevent the destroy 
> call (for example explicitly remove destroy from atexit list or use a 
> lock file in the avfs temp dir for some kind of reference counting). 
> BTW, can avfs handle shared tmp files between forked processes at all? A 
> solution could be the usage of pthread_atfork to recreate temporary 
> files for the child.

It's not designed to be fork safe unfortunately.  So if it works it's
purely by chance.

> Then there is serious problem with the character # inside filenames. I'm 
> aware that filenames containing for example #utar cannot be accessed but 
> atleast files with a # and other following characters not matching any 
> vfs extensions should be accessible. For example for a directory 
> containing a file "test#test" readdir will return "test##test" but lstat 
> on this name fails.

Hmm.  In theory it should work.  If it doesn't thats a bug.

> The directory /#avfsstat/cache has the inode 0 but inode 0 & 1 should 
> not be used (if 
> "http://www.gsp.com/cgi-bin/man.cgi?section=5&topic=inode" is true for 
> all filesystems).
> 
> A function "isLocal()" would really help me as I use the filecontent for
> filetype recognition and it is not always a good idea to read the files 
> in virtual directories (slow ftp or ssh). This way I can skip such files.

Something like this should work:

int is_local(const char *path)
{
	int isloc = 1;
	ventry *ve;

	res = av_get_ventry(path, 1, &ve);
	if (res == 0) {
		if (ve->mnt->base != NULL)
			isloc = 0;
		av_free_ventry(ve);
	}
	return isloc;
}

> The last release is 3 years old and I don't know about bugfixes. But is 
> there any reason I should not use AVFS for my filemanager?

I didn't really have time to keep up AVFS work, but I still haven't
lost the hope, that someday I can still update it.

> Do you mind if I use the latest CVS code and put it on my homepage
> so the user can use this?

Not at all. 

> I can implement some of the changes myself so if you accept patches I 
> will send them to the list.

OK, thanks.

Miklos


-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt