From project at digital-forensic.org Fri Mar 18 16:31:59 2011 From: project at digital-forensic.org (Digital Forensics Framework) Date: Fri, 18 Mar 2011 16:31:59 +0100 Subject: [dff] Digital Forensics Framework 1.0.0 released Message-ID: <4D837AEF.80900@digital-forensic.org> DFF 1.0.0 has just been released and can be downloaded at: http://www.digital-forensic.org/download ArxSys now offers a full range of professional software services and support associated with DFF and Open Source Digital Forensics technologies, please discover our offer at http://www.arxsys.eu. We would like to thank three new contributors: - Bram Mooij who has done the Dutch translation. - Dennis Schreiber who has done the German translation. - Francesco Acchiappati who has done the Italian translation. New Features: ------------- * Windows registry parsing: creates a tree of nodes for each key of a Windows registry hive file. Each node has registry values in its attributes (created time, data value, ...). * VMware VMDK reconstruction: This module reconstructs a volume from a vmdk file. It is able to reconstruct the base volume and the snapshots both. * MetaExif: EXIF information from picture files can now be added as node attributes. The metaexif module uses the dynamic attributes feature of the API so it has fewer memory footprint. * Timeline: constructs a graphical timeline generated from each timestamp attributes found in nodes (i.e. if you have applied NTFS, registry and metaexif modules, the timeline will be drawn from MAC times of NTFS, creation time of Windows registry and EXIF accessed and changed times). Once the timeline is drawn you can zoom on a date range and then export all nodes included in this range of time. * Translation: DFF GUI can now be hot-translated (no need to relaunch the application to use selected language). Also most widgets have been refactored using QtDesigner. * Column dynamic filtering: In the table-view of DFF nodes browser you can now add as many column as you want. Columns that can be added correspond to each attributes present in a node. So you can sort on any time attributes, size, deleted, or any other attributes. * Carver: You now have the posibility to add your own pattern (aka header, footer, wildcard) in the carver and to set for each header if it has to be sector aligned. Also, the carver can now be launched in console. * Merge: The merge module now takes a list of nodes as input. You can though virtually merge as many files as you need. For example, you can merge all files from split DD images and then apply other modules to the virtually reconstructed image. * Hash: module can now be applied directly with several algorithms (md5, sha1, sha256, ...) and uses the new dynamic attributes API to add calculated hashes as node attributes. It uses the post-processing feature. * Enhanced GUI ergonomy * Sort speed and display greatly enhanced. * Fast display of large number of items (> 100 000). * The GUI now has maximize and fullscreen buttons, to display widgets on the entire screen. * A new menu: relevant module, helps you for a fast access to the most relevant module to apply on a node. * A new menu: open as new tab, creates a new browser opened from a node (with children) you clicked on. * Each module can now have an associated icon. * When double-clicking on a node to auto-apply a module, a message box will popup in order to validate that the detected module must be applied. * The apply module widget has been totally rewritten to use the libtype API (Config and arguments of a module). * Configuration: DFF now has a configuration file, allowing to setup your favorite language, setting the path where history file will be saved and setting the path to the help documention. It also provides a "no footprint" mode when performing live analysis. * IDE update: IDE templates have been updated. The IDE syntax highlighter has been rewritten and no longer relies on QScintilla. * Versioning: Each library of the API and each module now have their own version number, allowing easy maintainability and upgrade. * API: * The config/argument and result classes were totally rewritten to be fully based on Variant. * Attributes are now fully based on Variant. Also modules can now add dynamic attributes to reduce memory footprint. * Data-type and compatible modules are now accessible directly from a node object. * Old file-type API has been replaced by the new data-type engine where you can plug your own data-type detection handler. * Variant enhancement: * It is now possible to force the handled raw type when using Variant in Python. * Comparison operators are implemented * ability to convert raw types to String, OctString and HexString * better conversion method (stringToInt, intToString, and so on) * Console: * Completion has been rewritten from scratch to be compliant with new Config / arguments API * It supports list of parameters and predefined parameters are now well handled * Write of a line tokenizer: * directly creates context used by the completion * supports "&" and "&&" classical shell keys and correctly manages threading and wait conditions Bug fixes: ---------- * ExtFs: Checks magic of number of Inodes to avoid crashes on crafted or damaged data. * Hex viewer pixel view: Fixes some crash when underlaying read do not return requested number of bytes. * Since most of the GUI Model / View has been refactored, lots of bugs have been resolved too. * Some thrown exceptions were not handled correctly resulting to the Aborted behaviour. -- contact at digital-forensic.org Main website: http://www.digital-forensic.org Documentation wiki: http://wiki.digital-forensic.org Project tracker: https://tracker.digital-forensic.org From csteger515 at gmail.com Tue Mar 22 01:33:53 2011 From: csteger515 at gmail.com (Curt Steger) Date: Mon, 21 Mar 2011 17:33:53 -0700 Subject: [dff] 1.0 crashes on Win XP Pro - 32 bit Message-ID: I just installed ver 1.0 on a windows box running the 32 - bit version of XP pro. I installed *DFF 1.0.0 with Python and PyQt installers included*. Everything works fine until I use the NTFS module to actually mount the file system. The system gets to approximately 35% then the program ends. The image I am trying to open is an 80G RAW image. It works just fine with an 8G image I made of a thumb drive. Unfortunately, I think it might be system related. I was given a P4 with 1G RAM (my agency love me) to conduct my forensic analysis of media. Does the amount of RAM impact DFF in windows; and would it cause it to crash? Went through the error logs, and found nothing to give a hint of what occurred or why. I should add if I mount the raw image through FTK Imager, DFF has no problem reading the drive. Thanks, Curt -------------- next part -------------- An HTML attachment was scrubbed... URL: From solal.jacob at ArxSys.fr Tue Mar 22 13:04:44 2011 From: solal.jacob at ArxSys.fr (Solal Jacob) Date: Tue, 22 Mar 2011 12:04:44 +0000 Subject: [dff] 1.0 crashes on Win XP Pro - 32 bit In-Reply-To: References: Message-ID: <4D88905C.7030306@ArxSys.fr> Hello, Thank you for the bug report. We already have encountered bug on the NTFS module and we are working to fix it. Also, we have done all our tests on a Windows virtualized environment ( all the developer are on linux ). It seem that DFF encounter many crash on native windows and even more when executed on multicore machine on windows. We will start working to fix that soon. For the RAM problem it will depend on the modules and the size of the data but most of DFF modules doesn't require much of RAM. It will be interesting if you can test on linux and told us if you have the same problem (for the image you need to mount trough FTK imager). Thanks, Solal. On 03/22/11 00:33, Curt Steger wrote: > I just installed ver 1.0 on a windows box running the 32 - bit version > of XP pro. I installed *DFF 1.0.0 with Python and PyQt installers > included*. Everything works fine until I use the NTFS module to > actually mount the file system. The system gets to approximately 35% > then the program ends. The image I am trying to open is an 80G RAW image. > > It works just fine with an 8G image I made of a thumb drive. > > Unfortunately, I think it might be system related. I was given a P4 > with 1G RAM (my agency love me) to conduct my forensic analysis of > media. Does the amount of RAM impact DFF in windows; and would it > cause it to crash? > > Went through the error logs, and found nothing to give a hint of what > occurred or why. > > I should add if I mount the raw image through FTK Imager, DFF has no > problem reading the drive. > > Thanks, > > Curt > > > _______________________________________________ > dff mailing list > dff at digital-forensic.org > http://lists.digital-forensic.org/listinfo/dff > -------------- next part -------------- An HTML attachment was scrubbed... URL: From solal.jacob at ArxSys.fr Tue Mar 22 16:17:59 2011 From: solal.jacob at ArxSys.fr (Solal Jacob) Date: Tue, 22 Mar 2011 15:17:59 +0000 Subject: [dff] Split images and DFF In-Reply-To: <4D5DCA62.2040704@ArxSys.fr> References: <4D5DCA62.2040704@ArxSys.fr> Message-ID: <4D88BDA7.3070000@ArxSys.fr> Hi, DFF 1.0 is released and we have made a blog post to explain how to manage DD splitted dump : http://www.arxsys.fr/blog/post/4/ Solal. On 02/18/11 01:24, Solal Jacob wrote: > Hi, > > In the current stable release (0.9) there is a merge modules that can > concatenate two files into one. > > You can load your files into DFF by using the menu : 'file'->'open > evidences' and then select your files. > After that they will appear in the node browser, right click on a node > then select : > 'Open With->Node->Merge'. A new window will apear that will permit you > to select the files that you want to merge. > To select the files use the 'browse' button and after that click 'ok' > this will create a new node representing the two merged files. > > This is certainly not enough for your usage, because you'll probably > need to merge more than two files. > > We are currently working on DFF 1.0 that will be released in March. > In this version the merge module will be able to take a list of nodes ( > files ). > This improvement will permit you to use this module to virtually > concatenate as many split dd files as you want in to one virtual file. > Which can then be used by other modules to reconstruct the underlaying > file system. > > > Solal. > > > On 02/17/11 22:17, Elizabeth Schweinsberg wrote: > >> Good afternoon, >> >> How does one add dumps that are split images to DFF? It's not >> immediately obvious and our test cases are all split dd files. The >> wiki doesn't give any suggestions either. >> >> Thanks! >> Elizabeth >> _______________________________________________ >> dff mailing list >> dff at digital-forensic.org >> http://lists.digital-forensic.org/listinfo/dff >> >> > _______________________________________________ > dff mailing list > dff at digital-forensic.org > http://lists.digital-forensic.org/listinfo/dff > -- Solal Jacob solal.jacob at arxsys.fr ArxSys, Riposte Num?rique 14-16, Rue du Soleillet 75020 Paris T?l: +33 1 46 36 25 22 www.arxsys.fr www.digital-forensic.org From mingmingtao at gmail.com Thu Mar 24 13:18:50 2011 From: mingmingtao at gmail.com (=?GB2312?B?zNXD98P3?=) Date: Thu, 24 Mar 2011 20:18:50 +0800 Subject: [dff] can't install DFF-1.0.0 on Mac osx 10.6.4 Message-ID: hi, everyone I can't install dff-1.0.0 on osx 10.6.4. I've installed PyQt, Qt, swig successfully. When I run make in source of dff-1.0.0, it shows error below. I?ve installed 32-bits PyQt. But the swig is 64-bits. did it cause the error? ... [ 1%] Built target testdeploy.testsuite.vfserrortest.py [ 1%] Built target api.__init__.py Linking CXX shared library _libexceptions.so ld: warning: in /Library/Frameworks//Python.framework/Python, missing required architecture x86_64 in file Undefined symbols: "__PyWeakref_CallableProxyType", referenced from: _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o "_PyString_AsStringAndSize", referenced from: SWIG_AsPtr_std_string(_object*, std::basic_string, std::allocator >**)in libexceptionsPYTHON_wrap.cxx.o "_PyGILState_Release", referenced from: SWIG_Python_SetErrorMsg(_object*, char const*)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_SetErrorMsg(_object*, char const*)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_SetErrorObj(_object*, _object*)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_SetErrorObj(_object*, _object*)in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o "__Py_NotImplementedStruct", referenced from: _SwigPyObject_richcompare in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o "_PyObject_IsTrue", referenced from: _SwigPyObject_own in libexceptionsPYTHON_wrap.cxx.o "_PyCObject_FromVoidPtr", referenced from: _SWIG_Python_TypeQuery in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_SetModule in libexceptionsPYTHON_wrap.cxx.o "_PyModule_AddObject", referenced from: _SWIG_Python_SetModule in libexceptionsPYTHON_wrap.cxx.o "_PyObject_CallFunctionObjArgs", referenced from: _SwigPyObject_dealloc in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_ConvertPtrAndOwn in libexceptionsPYTHON_wrap.cxx.o "_PyString_FromFormat", referenced from: _SwigPyObject_repr in libexceptionsPYTHON_wrap.cxx.o _SwigPyPacked_str in libexceptionsPYTHON_wrap.cxx.o _SwigPyPacked_repr in libexceptionsPYTHON_wrap.cxx.o _SwigPyPacked_repr in libexceptionsPYTHON_wrap.cxx.o "_PyDict_GetItem", referenced from: _SWIG_Python_TypeQuery in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o "_PyDict_SetItem", referenced from: _SWIG_Python_TypeQuery in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_InitShadowInstance in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_InitShadowInstance in libexceptionsPYTHON_wrap.cxx.o "__PyWeakref_ProxyType", referenced from: _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o "_PyLong_FromVoidPtr", referenced from: _SwigPyObject_long in libexceptionsPYTHON_wrap.cxx.o "_PyGILState_Ensure", referenced from: SWIG_Python_SetErrorMsg(_object*, char const*)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_SetErrorObj(_object*, _object*)in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o "_PyExc_OverflowError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyTuple_SetItem", referenced from: _SwigPyObject_format in libexceptionsPYTHON_wrap.cxx.o _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o "_PyString_Format", referenced from: _SwigPyObject_format in libexceptionsPYTHON_wrap.cxx.o "_PyObject_GetAttrString", referenced from: _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_InitShadowInstance in libexceptionsPYTHON_wrap.cxx.o "_PyBool_FromLong", referenced from: _SwigPyObject_own in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___eq__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___ne__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_equal in libexceptionsPYTHON_wrap.cxx.o "_PyArg_UnpackTuple", referenced from: _SwigPyObject_own in libexceptionsPYTHON_wrap.cxx.o "_PyEval_InitThreads", referenced from: _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o "_PyExc_ZeroDivisionError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyInt_AsLong", referenced from: SWIG_AsVal_long(_object*, long*) in libexceptionsPYTHON_wrap.cxx.o SWIG_AsVal_unsigned_SS_long(_object*, unsigned long*)in libexceptionsPYTHON_wrap.cxx.o "_PyDict_SetItemString", referenced from: _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o "_PyObject_Init", referenced from: _SwigPyObject_New in libexceptionsPYTHON_wrap.cxx.o _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o "_PyString_FromStringAndSize", referenced from: __wrap_envError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_get in libexceptionsPYTHON_wrap.cxx.o "_PyCObject_AsVoidPtr", referenced from: _SWIG_Python_TypeQuery in libexceptionsPYTHON_wrap.cxx.o "_PyExc_AttributeError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyCObject_Import", referenced from: _SWIG_Python_GetModule in libexceptionsPYTHON_wrap.cxx.o "_PyErr_SetString", referenced from: SWIG_Python_UnpackTuple(_object*, char const*, long, long, _object**)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_SetErrorMsg(_object*, char const*)in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o "_PyErr_SetObject", referenced from: SWIG_Python_SetErrorObj(_object*, _object*)in libexceptionsPYTHON_wrap.cxx.o "_PyString_FromString", referenced from: SWIG_Python_str_FromChar(char const*)in libexceptionsPYTHON_wrap.cxx.o "_PyString_AsString", referenced from: SWIG_Python_str_AsChar(_object*) in libexceptionsPYTHON_wrap.cxx.o "_PyExc_SyntaxError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyExc_IOError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyErr_Clear", referenced from: _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_GetModule in libexceptionsPYTHON_wrap.cxx.o SWIG_AsVal_long(_object*, long*) in libexceptionsPYTHON_wrap.cxx.o SWIG_AsVal_unsigned_SS_long(_object*, unsigned long*)in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_ConvertPtrAndOwn in libexceptionsPYTHON_wrap.cxx.o "_Py_InitModule4_64", referenced from: _SWIG_Python_SetModule in libexceptionsPYTHON_wrap.cxx.o _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o "_PyErr_Format", referenced from: SWIG_Python_UnpackTuple(_object*, char const*, long, long, _object**)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_UnpackTuple(_object*, char const*, long, long, _object**)in libexceptionsPYTHON_wrap.cxx.o "_PyObject_Malloc", referenced from: _SwigPyObject_New in libexceptionsPYTHON_wrap.cxx.o _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o "_PyExc_ValueError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "__Py_TrueStruct", referenced from: _SwigPyObject_richcompare in libexceptionsPYTHON_wrap.cxx.o "_PyExc_IndexError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyType_Type", referenced from: __PySwigObject_type in libexceptionsPYTHON_wrap.cxx.o __PySwigPacked_type in libexceptionsPYTHON_wrap.cxx.o "_PyExc_RuntimeError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_equal in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_distance in libexceptionsPYTHON_wrap.cxx.o "_PyObject_Free", referenced from: _SwigPyObject_dealloc in libexceptionsPYTHON_wrap.cxx.o _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o _SwigPyPacked_dealloc in libexceptionsPYTHON_wrap.cxx.o "_PyExc_StopIteration", referenced from: __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___isub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___iadd__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_value in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___add__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_advance in libexceptionsPYTHON_wrap.cxx.o "_PyModule_GetDict", referenced from: _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o "_PyExc_MemoryError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o "_PyInt_FromLong", referenced from: __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_distance in libexceptionsPYTHON_wrap.cxx.o "_PyExc_SystemError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_UnpackTuple(_object*, char const*, long, long, _object**)in libexceptionsPYTHON_wrap.cxx.o "__PyObject_GetDictPtr", referenced from: _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_InitShadowInstance in libexceptionsPYTHON_wrap.cxx.o "_PyObject_Call", referenced from: _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o "_PyErr_Occurred", referenced from: _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_GetModule in libexceptionsPYTHON_wrap.cxx.o SWIG_AsVal_long(_object*, long*) in libexceptionsPYTHON_wrap.cxx.o SWIG_AsVal_unsigned_SS_long(_object*, unsigned long*)in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_ConvertPtrAndOwn in libexceptionsPYTHON_wrap.cxx.o "_PyInstance_Type", referenced from: _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o "_PyObject_GenericGetAttr", referenced from: _tmp.9761 in libexceptionsPYTHON_wrap.cxx.o _tmp.9897 in libexceptionsPYTHON_wrap.cxx.o "_PyExc_KeyError", referenced from: __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o "__Py_ZeroStruct", referenced from: _SwigPyObject_richcompare in libexceptionsPYTHON_wrap.cxx.o "_PyObject_GetAttr", referenced from: _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o "_PyTuple_New", referenced from: _SwigPyObject_format in libexceptionsPYTHON_wrap.cxx.o _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o "_PyInstance_NewRaw", referenced from: _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o "_PyString_ConcatAndDel", referenced from: _SwigPyObject_repr in libexceptionsPYTHON_wrap.cxx.o "_PyDict_New", referenced from: _SWIG_Python_TypeCache in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_InitShadowInstance in libexceptionsPYTHON_wrap.cxx.o "_PyLong_AsLong", referenced from: SWIG_AsVal_long(_object*, long*) in libexceptionsPYTHON_wrap.cxx.o "_PyExc_NotImplementedError", referenced from: __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o "__Py_NoneStruct", referenced from: _SwigPyObject_disown in libexceptionsPYTHON_wrap.cxx.o _SwigPyObject_acquire in libexceptionsPYTHON_wrap.cxx.o _SwigPyObject_append in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_NewPointerObj in libexceptionsPYTHON_wrap.cxx.o _init_libexceptions in libexceptionsPYTHON_wrap.cxx.o _SwigPyObject_next in libexceptionsPYTHON_wrap.cxx.o _vfsError_swigregister in libexceptionsPYTHON_wrap.cxx.o _envError_swigregister in libexceptionsPYTHON_wrap.cxx.o _SwigPyIterator_swigregister in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_InitShadowInstance in libexceptionsPYTHON_wrap.cxx.o _SWIG_Python_ConvertPtrAndOwn in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___isub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___iadd__ in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_value in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___add__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_advance in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_SwigPyIterator in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o "_PyExc_TypeError", referenced from: SWIG_Python_ErrorType(int) in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_UnpackTuple(_object*, char const*, long, long, _object**)in libexceptionsPYTHON_wrap.cxx.o SWIG_Python_UnpackTuple(_object*, char const*, long, long, _object**)in libexceptionsPYTHON_wrap.cxx.o "_PyLong_AsUnsignedLong", referenced from: SWIG_AsVal_unsigned_SS_long(_object*, unsigned long*)in libexceptionsPYTHON_wrap.cxx.o "_PyEval_SaveThread", referenced from: __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___eq__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___ne__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___isub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_copy in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_equal in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___iadd__ in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_value in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___add__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_advance in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_distance in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_SwigPyIterator in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o "__PyInstance_Lookup", referenced from: _SWIG_Python_GetSwigThis in libexceptionsPYTHON_wrap.cxx.o "_PyClass_Type", referenced from: _SwigPyClientData_New in libexceptionsPYTHON_wrap.cxx.o "_PyThread_allocate_lock", referenced from: __static_initialization_and_destruction_0(int, int)in libexceptionsPYTHON_wrap.cxx.o "_PyEval_RestoreThread", referenced from: __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_decr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_incr in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_previous in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___next__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___sub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___eq__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___eq__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___ne__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___ne__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_next in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___isub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___isub__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_copy in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_copy in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_equal in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_equal in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___iadd__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___iadd__ in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_value in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_value in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___add__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator___add__ in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_advance in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_advance in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_distance in libexceptionsPYTHON_wrap.cxx.o __wrap_SwigPyIterator_distance in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_envError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_SwigPyIterator in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_SwigPyIterator in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_get in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_vfsError_error_set in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_new_vfsError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o __wrap_delete_envError in libexceptionsPYTHON_wrap.cxx.o ld: symbol(s) not found collect2: ld returned 1 exit status make[2]: *** [api/exceptions/_libexceptions.so] Error 1 make[1]: *** [api/exceptions/CMakeFiles/_libexceptions.dir/all] Error 2 make: *** [all] Error 2 -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.malinge at arxsys.fr Fri Mar 25 16:48:10 2011 From: christophe.malinge at arxsys.fr (Christophe Malinge) Date: Fri, 25 Mar 2011 16:48:10 +0100 Subject: [dff] can't install DFF-1.0.0 on Mac osx 10.6.4 In-Reply-To: References: Message-ID: <4D8CB93A.9020905@arxsys.fr> On 03/24/11 13:18, ??? wrote: > hi, everyone Hello ! > > I can't install dff-1.0.0 on osx 10.6.4. This is known for 64 bits MacOSX. Unfortunately there is no workaround today, due to the fact DFF team haven't access to 64 bits MacOSX. > > I've installed PyQt, Qt, swig successfully. > > When I run make in source of dff-1.0.0, it shows error below. > > I?ve installed 32-bits PyQt. But the swig is 64-bits. did it cause the > error? Sure, there is a problem between 32 bits and 64 bits for Python in the given log. As far as i know good/full 64 bits support on Apple's OS is actually unavailable. We encounter the same problem for Windows, there was no Python-QT 64 bits until recently, this is why we made the choice to only release one 32 bits Windows version. I do not think it can help, but this is related to MacOSX: Changes has just been pushed on the master branch of the GIT making DFF able to run on MacOSX 32 bits. I successfully tried it on Mac OSX.5.5 32 bits. Kind regards, Christophe. -- Christophe Malinge DFF, Core developer, System administrator ArxSys SAS, Directeur des syst?mes d'information T?l: +33 1 46 36 25 22 From mingmingtao at gmail.com Sat Mar 26 03:51:13 2011 From: mingmingtao at gmail.com (=?GB2312?B?zNXD98P3?=) Date: Sat, 26 Mar 2011 10:51:13 +0800 Subject: [dff] build successfully, but can't run dff on mac Message-ID: Hi, I've build dff on mac successfully. But when I run "python dff.py" in the build directory, it throws error below: import magic File "build/bdist.macosx-10.3-fat/egg/magic.py", line 128, in ImportError: failed to find libmagic. Check your installation Anybody can help me to resolve it? I think perhaps the the python-magic use the libmagic.dylib for mac. If I want run dff on mac, I have to wrap a libmaic.dylib with swig? Any suggestion is appreciated. mingming -------------- next part -------------- An HTML attachment was scrubbed... URL: From christophe.malinge at arxsys.fr Sat Mar 26 04:53:34 2011 From: christophe.malinge at arxsys.fr (Christophe Malinge) Date: Sat, 26 Mar 2011 04:53:34 +0100 Subject: [dff] build successfully, but can't run dff on mac In-Reply-To: References: Message-ID: <4D8D633E.6020907@arxsys.fr> On 03/26/11 03:51, ??? wrote: > Hi, > > I've build dff on mac successfully. But when I run "python dff.py" in > the build directory, it throws error below: > > import magic > File "build/bdist.macosx-10.3-fat/egg/magic.py", line 128, in > ImportError: failed to find libmagic. Check your installation > > Anybody can help me to resolve it? > I think perhaps the the python-magic use the libmagic.dylib for mac. > If I want run dff on mac, I have to wrap a libmaic.dylib with swig? > > Any suggestion is appreciated. > > mingming Hello mingming, What a good news to know it is almost working on OSX ! No need to wrap libmagig with swig ;) I had this problem on 32 bits ; the solution is to build and install libmagic.dylib from file package, and python-magic from a second source. But if you already have a magic.py binding this second step should not be necessary. Have a look at ftp://ftp.astron.com/pub/file/ to get file-5.05.tar.gz , and as usual ./configure && make install if I remember well. For the bindings, I used that from Ahupp: https://github.com/ahupp/python-magic . I hope it'll work ! Kind regards, Christophe. -- Christophe Malinge DFF, Core developer, System administrator ArxSys SAS, Directeur des syst?mes d'information T?l: +33 1 46 36 25 22