2009/5/9 mike _ <arizonagroovejet at gmail.com>: > > I'm not in a position to try the python you posted until Monday but > I'll try it both on a file that is several megabytes in an NFS home > directory and one of the much smaller files on the local disk and post > the results. I've tried the Python you suggested on both a file in an NFS mounted home directory and a home directory on the local disk. In both cases I got the error 'resource temporarily unavailable' but when I copied the files in to /tmp and used the Python on them it worked. For both files the result was the same: source:alsa_output.pci_8086_27d8_sound_card_0_alsa_playback_0.monitor source:alsa_input.pci_8086_27d8_sound_card_0_alsa_capture_0 None Yet one file is 13K, the other 3.1M. If I copy the 13k file to an NFS home directory and look at it's size, it still shows as 13k. If I 'tar zcf' the files the resulting .tgz file for the 13k file is 601bytes and for the 3.1M file it's 6.6k. So the compression ratio on the 3.1M file is way, way higher. I decided to see if I could somehow create a gdbm database myself and found this example of how to do it with python. http://mail.python.org/pipermail/tutor/2003-August/024819.html Using that example to create a gdbm database on the local disk resulted in a file which is 13K. See if you can guess how big the file was when I did the same in an NFS mounted home directory........ Yep, 3.1M. So it seems that file size discrepancies are not caused by pulseaudio but by gdbm. Or by gdbm+NFS. Or gdbm+NFS+the file system in use. Or something. Not pulseaudio anyway. That leaves the issue of pulseaudio not working and saying ""failed to create secure directory: permission denied" when ~/.pulse is a symlink to somewhere on the local harddisk. Anyone got any ideas on that? thanks, mike
