Download & Extend

MIME headers lost / mixed up when uploading files from a WebDav client

Project:File Server
Version:6.x-1.0-alpha3
Component:Code
Category:bug report
Priority:critical
Assigned:Unassigned
Status:active

Issue Summary

This looks like a bug, but it may have something to do with my sever configuration
I never got MIME detection working correctly.
This time, ppt files are recognzed as doc files, with the .doc extension added to the file name in addition to .ppt fiel original extension.

I tried the 3 possible setting of "Server-side MIME type autodetection after upload:" in admin/settings/file/mime
- "enabled" changes ppt to doc
- "disabled" makes ppt not regognized as such
- "Conditionnal" did the same than "enabled"

.doc and .pdf files are correctly handled

the "disabled" option makes none of the file types to be recognized

What do I have to look on the server side in order to benefit of a "natural" Apache detection instead of the buggy FF's ?

Thanks

Comments

#1

Project:File Framework» File Server
Version:6.x-1.x-dev» 6.x-1.0-alpha3
Component:Documentation» Code
Category:support request» bug report
Priority:normal» critical

Update: there are problems only when uploading files from a WebDav client, through File Server / DAV API.

So this should be a problem with the File (taxonomy) server module

#2

Title:MIME detection issue» MIME headers lost / mixed up when uploading files from a WebDav client

#3

Please help!
This is a great module, and the last problem I encounter with it

Thank you

#4

Anyone listening?

#5

Anyone listening?
Is this module maintained?

#6

Heeeeeeeeeeeeeeeeeeeeellllllllllllllllllllllllllllllllllllooooooooooooooooooooo!

Unmaintained module?

#7

Refreshing the topic

#8

Hi jvieille,

I got the same problem as you - and I found a solution.

Well, I am not a pro more an amateur and maybe my solution is far from perfect (I suppose it) but it works (at least for me).

I changed the function _fileserver_create_file in fileserver.module and copied some code from the fileframework module in it. Now the mimetype is detected on uploading via webdav.

This is what the function looks like now:

<?php
function _fileserver_create_file($tid, $name, $options, $filepath) {
  global
$user;

 
// Ensure the user has privileges to create nodes of this type. This is
  // the last chance for access controls to fail, unless some node module
  // does weird things in hook_validate(), hook_submit() or hook_save().
 
$mymimetype=$options['content_type'];
  if (!
user_access('create file content'))
    return
STATUS_403; // Forbidden

  // manually create an upload object, saving conversions for the cron step

 
if (empty($options['content_type']) || $options['content_type'] == 'application/octet-stream') {
     
$registry = file_mime_extensions();
     
$pathinfo = pathinfo($name);
     
$extension = $pathinfo['extension'];
      foreach (
$registry as $type => $extensions) {
        if (
in_array($extension, $extensions)) {
         
$testguess = $type;
        }
      }
   
$mymimetype = $testguess;
  }
   
  if (
FILE_MIME_AUTODETECTION > 0 && ($mime = file_mime_detect($file))) {
   
$mymimetype = $mime;
  }
 
 
$upload = (object)array(
   
'filename'  => $name,
   
'filepath'  => $filepath,
   
'filemime'  => $mymimetype,
   
'filesize'  => filesize($filepath),
   
'noconvert' => TRUE,
  );

 
// according to FileFramework API, make it 'nosave'
 
$node = (object)array(
   
'nosave' => TRUE,
  );

 
// save into Bitcache and RDF
 
if (file_node_save($node, $upload)) {
   
// Organic group vocabularies (og_vocab.module) integration: implicit
    // audience selection if the currently-selected taxonomy category is
    // related to an organic group.
   
$og_groups = array();
    if (
module_exists('og_vocab')) {
      if (
$term = taxonomy_get_term($tid)) {
        if (
$og_group = db_result(db_query('SELECT nid FROM {og_vocab} WHERE vid = %d', $term->vid))) {
         
$og_groups[$og_group] = (string)$og_group;
        }
      }
    }

   
// actually create the file node
   
$node = file_node_create(array(
     
'file'      => $node->file,
     
'taxonomy'  => array($tid),
     
'og_groups' => $og_groups,
    ));

    return (bool)
$node;
  }

  return
FALSE; // Something must've gone wrong
}
?>

I am sure it is not elegant but I did not have much time and only a little desire to dive deeper into the code of fileframework and fileserver. At least it works.

One more thing I discovered is the conversion and indexing on a cron run.

When you upload a file via WEBDAV it does not get converted imediately. Conversion is done on cron run. The order of the default cron run is not ok for this because it first updates the search index and then does file conversions. This means that PDF files that I added via WEBDAV did not get indexed. So I installed SuperCron (http://drupal.org/project/supercron) and changed the cron run order.

Hope I could be of any help for you.

Thomas

#9

I don't use much Webdav anymore as this is a quite unstable and unsupported feature by modern OS.
XP and Vista does not work, I only find one workable solution, Bitkinex, which is a dead project.
Thanks anyway

#10

Hi @jvieille

Webdav seems fine as long as you don't expose it directly to the end clients. I use DAVFS2 to mount the webdav to a mount point (eg /mnt/drupal_dav/) and then use Samba to share that directory out. Means you get the stability and cross platform support of Samba/mapped drives (and then easily LDAP authz) and the awesomeness of 'virtual' folders (taxomony/tags) and Fileframework goodness. Make sure in your /etc/davfs2/davfs2.conf that use_locks is turned off (0) as the php PEAR webdav server technology behind the drupal dav module doesn't support locking. And that is why webdav directly to the client doesnt work great in Win 7 or OSX (kinda works in XP, and if you use Cyberduck etc). But davfs2 can connect as dav level 1 (no locking) and it seems to work fine, and I'm testing with 1-2GB video files.

@skeezix: Thanks for your patch and suggestion to use SuperCron. I'll give them a go.

Fileserver seems more stable than Filerelationserver. If I enable both then put's into the taxonomy folders on FS dont work. Works fine if FRS is disabled.

Cheers,
Christiaan Kortekaas

#11

Thanks for the suggestion.
I reached the same conclusion about FRS ans FS, though FS seems not supported and FRS is the recommended module by FF maintainers (because of its OG awareness I suppose)

nobody click here