On Mon, 2008-08-18 at 17:23 -0700, wnielson wrote:
> For what its worth, I did manage a work around on the NFS side. In /
> etc/export you need to have the `no_subtree_check` option enabled.
> Apparently this has mild security implications (as stated in man
> exports), but it does allow the lock
For what its worth, I did manage a work around on the NFS side. In /
etc/export you need to have the `no_subtree_check` option enabled.
Apparently this has mild security implications (as stated in man
exports), but it does allow the locking to work properly.
Thanks for the insight Malcolm.
Chee
On Mon, 2008-08-18 at 16:42 -0700, wnielson wrote:
> Thanks for the quick response. Yes, I did do some searching and ran
> across the post about NFS (and yes I am using an NFS mount). However,
> I can solve the problem by bypassing the `save` method like so:
>
> from django.core.files import F
Thanks for the quick response. Yes, I did do some searching and ran
across the post about NFS (and yes I am using an NFS mount). However,
I can solve the problem by bypassing the `save` method like so:
from django.core.files import File
f = open('my_filename.jpg', 'w')
myfile = File(f)
myfile.
On Mon, 2008-08-18 at 16:05 -0700, wnielson wrote:
> I've been running into an issue while trying to upgrade my code to use
> Django's new file handling system. When I try to use the `save`
> method of a `ImageField` instance, I get an `IOError: [Errno 37] No
> locks available`. The file gets c
I've been running into an issue while trying to upgrade my code to use
Django's new file handling system. When I try to use the `save`
method of a `ImageField` instance, I get an `IOError: [Errno 37] No
locks available`. The file gets created but nothing is ever written
to it. Here is a basic e
6 matches
Mail list logo
