search

macressler / alfresco-bulk-filesystem-import

Automatically exported from code.google.com/p/alfresco-bulk-filesystem-import
GNU Lesser General Public License v3.0
1 stars 0 forks source link

Windows: incorrect paths being written into content store URLs #125

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
What steps will reproduce the problem?
1. Install alfresco-bulk-filesystem-import-1.2.1.amp on Alfresco 4.2.b 
Community Edition, installed with defaults + records management on Windows 7
2. Perform in-place import to an RM folder (if that makes any difference)using 
web gui. Import either Office docs or TIFF.
3. Navigate and select file in Share. Preview window displays message "The 
preview could not be loaded from the server."

Turns out in database that public_alf_content_url.content_url contains absolute 
path, e.g. 
store://C:\Alfresco\alf_data\contentstore\bulk-imports\import-src-one\1D-quadrup
le_VennA.tiff

Changing to relative path (plus index rebuild for some cases) will fix, e.g. 
store://bulk-imports/import-src-one/1D-quadruple_VennA.tiff

Original issue reported on code.google.com by matthew....@northweststate.edu on 11 Mar 2013 at 5:30

GoogleCodeExporter commented 9 years ago

Original comment by pmo...@gmail.com on 11 Mar 2013 at 5:38

GoogleCodeExporter commented 9 years ago 
This also causes failure of in-place import on Linux. With a Postgresql error, 
because the url is too long (255 chars).

I think this mehtod is to blame: 
http://code.google.com/p/alfresco-bulk-filesystem-import/source/browse/src/main/
java/org/alfresco/extension/bulkfilesystemimport/impl/AbstractBulkFilesystemImpo
rter.java?r=0713c598431dac2800ba372bbe81a59a11d7c341

  private final ContentData buildContentProperty(final ImportableItem.ContentAndMetadata contentAndMetadata)
    {
        ContentData result = null;

        String contentUrl = FileContentStore.STORE_PROTOCOL + ContentStore.PROTOCOL_DELIMITER + contentAndMetadata.getContentFile().getAbsolutePath().replace(configuredContentStore.getRootLocation() + OS_FILE_SEPARATOR, "");
        String mimeType   = mimeTypeService.guessMimetype(contentAndMetadata.getContentFile().getName());
        String encoding   = DEFAULT_TEXT_ENCODING;

        if (mimeTypeService.isText(mimeType))
        {
            encoding = guessEncoding(contentAndMetadata.getContentFile(), mimeType);
        }

        result = new ContentData(contentUrl, mimeType, contentAndMetadata.getContentFileSize(), encoding);

        return(result);
    }

Original comment by tass01...@gmail.com on 16 Apr 2013 at 11:19

GoogleCodeExporter commented 9 years ago 
The best way to get around the column length issue (which is not limited to 
PostgreSQL btw) is to stream content into the repository, instead of relying on 
in-place imports.  The tool can't help if source paths, relative to the content 
store root, are longer than 255 characters and an in-place import is initiated 
- Alfresco doesn't support content URLs that long.

It could be argued that this is a bug in Alfresco i.e. that content URLs should 
be allowed to be longer than 255 characters in length.  If you feel that this 
is the case I'd encourage you to raise a JIRA (at http://issues.alfresco.com/) 
or, if you're an Enterprise subscriber, a customer support case (at 
http://support.alfresco.com), then report back here so that I can cross-link 
the issues.

Original comment by pmo...@gmail.com on 25 Sep 2013 at 6:33

GoogleCodeExporter commented 9 years ago 
Note: the original issue (invalid content URLs on Windows) remains a problem 
that I'm going to investigate for v1.3.

Original comment by pmo...@gmail.com on 25 Sep 2013 at 6:34

GoogleCodeExporter commented 9 years ago 
This issue was closed by revision f80d6ca51cbc.

Original comment by pmo...@gmail.com on 18 Nov 2013 at 3:36