fsmount temp:// do not work (only works with -f)

[GoogleCodeExporter]

What steps will reproduce the problem?
1. mkdir test
2. fsmount temp:// test
3. ls test

What is the expected output? What do you see instead?

An empty temporary directory, but instead "no such file or directory"

What version of the product are you using? On what operating system?

r592, Python 2.7.1, Linux 2.6.36 x86_64

Please provide any additional information below.

fsmount -f temp:// works fine so it may be a problem with forking or something 
like that. Note that I am using Archlinux so /usr/bin/python is python3.1 and 
/usr/bin/python2 is python2.7.

Original issue reported on code.google.com by delroth on 31 Dec 2010 at 4:31

[GoogleCodeExporter]

It's a problem with forking and garbage collection -when the TempFS goes out of 
scope in the spawning process, its __del__ method gets called and the directory 
is deleted.  The spawned process is then left with a TempFS object pointing to 
a deleted directory.

A similar problem exists when e.g. pickling and unpickling a TempFS.

I usually work around this issue in code by using LazyFS to delay the tempdir 
creation, like this:

   fuse.mount(LazyFS(TempFS))

The tempfs is thus not created in the spawning process at all, only in the 
spawned process when it is first accessed.

Not sure how to do this properly in the command-line tools though.  One option 
would be to have the temp:// opener apply LazyFS automatically.  Attached patch 
makes `fsmount temp:// test` work for me, but I haven't thought through all the 
implications.

Original comment by rfkel...@gmail.com on 31 Dec 2010 at 4:53

Attachments:

• fsopener.patch

[GoogleCodeExporter]

I think I fixed that particular issue with TempFSs. When you pickle a TempFS 
now, it marks it as cleaned, and when you unpickle it, it marks it as 
uncleaned. Not sure how much of a hack that is.

The fsmount command doesn't actually use the pickling. When it forks, it just 
runs one fuse process in the foreground, like this:

    if not os.fork():                
        mp = fuse.mount(fs,
                        mount_path,
                        foreground=True)

Which appeared to work perfectly up to now! But having tested it on my laptop I 
can reproduce the issue, which occurs with any FS type as far as I can tell. If 
it actually is the same issue -- there are too many black boxes for me to be 
sure!

I'll try and reproduce it on my desktop machine, when I get out of the coffee 
shop.

Original comment by willmcgugan on 31 Dec 2010 at 10:57

• Changed state: Accepted

[GoogleCodeExporter]

AFAICT, the forking logic would result in the same bad state as 
pickling/unpickling - two instances of TempFS in two separate processes, both 
pointing to the same underlying directory and each thinking it has the 
responsibility to clean up the tempdir on close.

Original comment by rfkel...@gmail.com on 31 Dec 2010 at 11:02

[GoogleCodeExporter]

AFAICT, the forking logic would result in the same bad state as 
pickling/unpickling - two instances of TempFS in two separate processes, both 
pointing to the same underlying directory and each thinking it has the 
responsibility to clean up the tempdir on close.

Original comment by rfkel...@gmail.com on 31 Dec 2010 at 11:05

[GoogleCodeExporter]

Ah. You're right.

Perhaps the original process should replace the close method of the FS with a 
dummy function that does nothing.

Original comment by willmcgugan on 31 Dec 2010 at 11:18

[GoogleCodeExporter]

Turns out my user account on my laptop wasn't a member of the fuse group. 
Changing that fixed my issues with fsmount, and the dummy close change appears 
to have fixed the Delroth's issue.

Delroth, please test that fix in trunk and let me know how it goes.

Original comment by willmcgugan on 31 Dec 2010 at 11:46

• Changed state: Started

[GoogleCodeExporter]

Sorry, I could not test this until right now. It seems to work fine with sshfs, 
temp and mem, so I guess the issue is fixed :)

Thanks a lot!

Original comment by delroth on 3 Jan 2011 at 4:18

[GoogleCodeExporter]

Cool.

Original comment by willmcgugan on 3 Jan 2011 at 9:43

• Changed state: Fixed