Tracker log

An overview of recent activity in the tracker.

Diogo Moreira added a new response to »"AttributeError: portal_properties" when importing .zexp or copying Plone Site«:

I'm using Plone 3.3.4 and I'm still having this trouble to import my Plone Site into another instance in the same server. How can I do to fix this?

Thanks a lot.

Added 311 day(s) ago.

New issue »Update http://products.ingeniweb.com/catalog/iw.fss« added by Jean Jordaan

http://products.ingeniweb.com/catalog/iw.fss states:

"Report bugs using the tracker (the Tracker link from http://plone.org/iw.fss)."

The link should be
http://plone.org/products/filesystemstorage/issues

Added 513 day(s) ago.

New issue »Migration cannot handle all instance types form FileField« added by Webworks

Version 2.8rc3 tested.

The following monkeypatch allows iw.fss to migrate fields with OFS.Image.Pdata instances as values. This happened on our server when tarballs (.tar.gz files) where stored. OFS.Image.Pdata does not have a "read" method and so iw.fss.FileSystemStorage.FileUploadIterator throws an error. Here's the monkey patch:

import cgi
from ZPublisher.HTTPRequest import FileUpload
import cStringIO
from iw.fss.FileSystemStorage import FileUploadIterator

old__init__ = FileUploadIterator.__init__

def new__init__(self, file, streamsize=1<<16):
    """ this is a file upload """
    if not hasattr(file, 'read') and hasattr(file,'data'):
        data = str(file) # see OFS.Image.Pdata
        fs = cgi.FieldStorage()
        fs.file = cStringIO.StringIO(data)
        file = FileUpload(fs)
    return old__init__(self, file, streamsize)

Added 581 day(s) ago.

New issue »Invalid cross-device link when storage on different mounted volumes (switch away from os.rename)« added by Webworks

Tested on version 2.8rc3

Many unixish systems have different directories (/tmp, /home, /var and so on) on different mounted volumes. Python's os.rename cannot handle this and therefore the code in iw.fss that uses os.rename cannot handle the storage being on a different mounted volumes (say, on "/var/www/html", when the Plone site is a buildout in the "/home" hierarchy). shutil.move may be an alternative to os.rename .

Added 582 day(s) ago.

Alter Way Solutions added a new response to »iw.recipe.fss ignoring 'conf' parameter«:

Hi Andreas,

You should not use "conf" *and* "zope-instances" options. Hint : remove the "conf" option.

I agree this should now raise an error from buildout.

In addition "zope-instances" expects a list of... zope instances ;). You provide a Zope "core" location.

Try this, assuming your part for "plone.recipe.zope2instance" is "instance":

[buildout]
...
# fss must be **after** the last zope instance/zeo client part
parts =
    ...
    instance
    ...
    fss
    ...

[instance]
recipe = plone.recipe.zope2instance
...

[fss]
recipe = iw.recipe.fss
zope-instances =
    ${instance:location}

storages =
    ...

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → ingeniweb.
Added 644 day(s) ago.

New issue »iw.recipe.fss ignoring 'conf' parameter« added by Andreas Jung

Plone 3.3.2
iw.fss 2.8.0
iw.recipe.fss 0.2.1

The following part is used for our Plone configuration.
iw.fss is unabl to pick up the configuration from the file in 'conf'. Instead is uses parts/instance/etc/plone-filesystemstore.conf instead. 'conf' seems to be completely ignored.

Any idea why?

[fss]
recipe = iw.recipe.fss
## Deprecated
#conf = ${buildout:directory}/etc/plone-filesystemstorage.conf
conf = /usr/local/www/ZopeInstances/bentest3/etc/plone-filesystemstorage.conf
# Replacement for 'conf' option
zope-instances =
${zope2:location}
storages =
default_storage /parts/zope2 directory /data/bentest2/fss_storage /data/bentest2/fss_backup

Added 644 day(s) ago.

Andreas Gabriel added a new response to »Upload of large files results in memory error«:

Now the marshaller can be individually configured via zcml configuration for each portal_type (see patch in attachment).

Added 658 day(s) ago.

Andreas Gabriel added a new response to »Upload of large files results in memory error«:

I have now found a solution of the problem. There was a hint in Products.Marshall.marshaller to switch to PrimaryFieldMarshaller for large file uploads. The
method "patchATType" of iw.fss has also to change the default marshaller of portal type's schema (see patch in attachment)

Added 658 day(s) ago.

Andreas Gabriel added a new response to »Upload of large files results in memory error«:

Large file upload (fss 2.8.0rc3) via web form works now, but
upload via webdav results also in MemoryError

Traceback (innermost last):
  Module ZPublisher.Publish, line 119, in publish
  Module ZPublisher.mapply, line 88, in mapply
  Module ZPublisher.Publish, line 42, in call_object
  Module webdav.NullResource, line 167, in PUT
  Module Products.Archetypes.WebDAVSupport, line 116, in PUT
  Module Products.Archetypes.utils, line 160, in mapply
  Module Products.Marshall.marshaller, line 99, in demarshall
MemoryError

Issue state: Resolved → Confirmed.
Added 658 day(s) ago.

Alter Way Solutions added a new response to »Move iw.recipe.fss to Collective SVN«:

ok no problem.
Sorry for answer in late, we didn't receive mail (config is ok now)

Issue state: Unconfirmed → Confirmed.
Responsible manager: (UNASSIGNED) → ingeniweb.
Target release: None → 2.8rc2.
Added 664 day(s) ago.

Alter Way Solutions added a new response to »SystemError: Negative size passed to PyString_FromStringAndSize while uploading a file through FSS«:

try with 2.8.0rc3, we have worked on the upload process.
As I see ,in you're traceback there is no code related to fss, but on wicked.fieldevent that is responsable I suppose of this bug.

Regards Youenn.

Issue state: Unconfirmed → Rejected.
Responsible manager: (UNASSIGNED) → ingeniweb.
Added 664 day(s) ago.

Alter Way Solutions added a new response to »buildout destroys storage«:

You can use the recipe iw.recipe.fss to configure fss and generate config file (http://pypi.python.org/pypi/iw.recipe.fss)

Don't use the var of the instance part but the var of you're buildout part (${buildout_directory}/var} as filestorage of the zodb do. The recipe that build instance delete var directory every buildout launch !!

You can use collective.recipe.backup to save fss files in backup to.

Issue state: Unconfirmed → Rejected.
Responsible manager: (UNASSIGNED) → ingeniweb.
Added 664 day(s) ago.

Alter Way Solutions added a new response to »str-method on fss-content doesn't work«:

fix on 2.8.0rc3

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → ingeniweb.
Target release: None → 2.8rc2.
Added 664 day(s) ago.

Alter Way Solutions added a new response to »Upload of large files results in memory error«:

fix on 2.8.0rc3

Issue state: Unconfirmed → Resolved.
Responsible manager: (UNASSIGNED) → ingeniweb.
Target release: None → 2.8rc2.
Added 664 day(s) ago.

New issue »str-method on fss-content doesn't work« added by Tom Gross

Calling the str-method on a fss-field raises an AttributeError:

str(obj.getPrimaryField().get(obj))

  File "/webserver/buildouts/common/eggs/iw.fss-2.8.0rc2-py2.4.egg/iw/fss/FileSystemStorage.py", line 229, in __str__
    return str(self.getData())
  File "/webserver/buildouts/common/eggs/iw.fss-2.8.0rc2-py2.4.egg/iw/fss/FileSystemStorage.py", line 219, in getData
    return FSSPdata(xrange(0))
  File "/webserver/buildouts/common/eggs/iw.fss-2.8.0rc2-py2.4.egg/iw/fss/FileSystemStorage.py", line 153, in __init__
    self.data = self.__g.next()
AttributeError: 'xrange' object has no attribute 'next'

The call worked with 2.8.0rc1

Added 666 day(s) ago.

(anonymous) added a new response to »fss creates failure in fss.cfg«:

Added 686 day(s) ago.

(anonymous) added a new response to »FSS content is not correctly returned when dispatched inline«:

Added 686 day(s) ago.

(anonymous) added a new response to »FSS content is not correctly returned when dispatched inline«:

Added 686 day(s) ago.

(anonymous) added a new response to »FSS content is not correctly returned when dispatched inline«:

Added 687 day(s) ago.

(anonymous) added a new response to »FSS content is not correctly returned when dispatched inline«:

Added 687 day(s) ago.