permanent mount

Ext2Fsd
2006-11-12
2013-04-09
  • Nobody/Anonymous

    I'm curious about the permanent mount feature.

    When I try to use it I am prompted with "Woudl you like to modify the partition type to NTFS to make this linux volume properly recognized?"

    Will this damage the partition or make it unrecognizable to linux?

     
    • Nobody/Anonymous

      The feature is for basic type disk partitions. It changes the partition id from Linux (0x83) to Windows NTFS (0x07 via theIOCTL_DISK_SET_DRIVE_LAYOUT. It DOES change the partition table, DOES NOT touch the volume data.

      So "fdisk -l" will show it's NTFS type, but it won't bother the mounting process to be recognized by ext2/ext3 under Linux.

       
    • Matt Wu

      Matt Wu - 2006-11-13

      The feature is for basic type disk partitions. It changes the partition id from Linux (0x83) to Windows NTFS (0x07) via IOCTL_DISK_SET_DRIVE_LAYOUT. It DOES change the partition table, DOES NOT touch the volume data.

      So "fdisk -l" will show it's NTFS type, but it won't bother the mounting process to be recognized by ext2/ext3 under Linux.

       
      • Giuseppe Bilotta

        According to a few pages on MSDN I've read, to support automatic mounting of volumes, the driver must define a GUID. I can't find the page again, but maybe something like http://msdn.microsoft.com/library/default.asp?url=/library/en-us/storage_d/hh/Storage_d/03class_c68c54a8-82a4-45c6-9066-8f1f099aa32f.xml.asp can direct you to the proper interfaces.

         
        • Matt Wu

          Matt Wu - 2006-11-15

          The GUID is created by MountMgr when it get the events of new volume arrival and it only handle the nt recoginized volumes (FAT, NTFS, CDFS ...) It uses an internal database to manage all the mount points.

          MountMgr uses a PlugPlay callback to monitor device changes (arrival,removal). It also provides an ioctl IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION for manual volume handling. Later I'll have a try on it.

           
          • Giuseppe Bilotta

            You are probably already familiar with this (quoted from http://msdn2.microsoft.com/en-US/library/ms802377.aspx --hope it's still available)

            <blockquote>
            The mount manager relies on the Plug and Play device interface notification mechanism to alert it of volume arrival and removal. Therefore every client (that is, every volume driver, usually a class driver) must create an interface in the MOUNTDEV_MOUNTED_DEVICE_GUID interface class by calling IoRegisterDeviceInterface to notify the mount manager of the arrival in the system of the volume it manages. The MOUNTDEV_MOUNTED_DEVICE_GUID interface class GUID is defined in mountmgr.h.

            Upon receiving a Plug and Play notification of the arrival of a volume interface, mount manager sends the client three device control IRPs:

            IOCTL_MOUNTDEV_QUERY_DEVICE_NAME
            IOCTL_MOUNTDEV_QUERY_UNIQUE_ID
            IOCTL_MOUNTDEV_QUERY_SUGGESTED_LINK_NAME

            In response to these three IOCTLs the client should return the volume's nonpersistent device object name (or target name) located in the Device directory of the system object tree (for example: "\Device\HarddiskVolume1"), the unique volume ID, and a suggested persistent symbolic link name for the volume, respectively. Although clients may elect to ignore the first and third of these three IOCTLs, they are required to provide a unique volume ID upon receiving IOCTL_MOUNTDEV_QUERY_UNIQUE_ID. The mount manager relies entirely upon the client to provide the unique volume ID, and if the client does not provide it, then the mount manager is not able to assign mount points, such as drive letters, to the volume.
            </blockquote>

            Concerning the reconized filesystem: does MountMgr rely on the ones recongized by fs_rec.sys <i>only</i>, or is it possible to add other recognizers? Wasn't there an ext2fsr.sys driver that acted as a recognizer at some time in the project? Maybe you could resurrecting it to handle this part of the job, i.e. recognizing the filesystem and informing MountMgr about all ext2 volumes.

             
            • Matt Wu

              Matt Wu - 2006-11-16

              MountMgr relies on "Volume Manager", which enums and inititalizes all the volumes.

              When ext2fsd is loaded as system starts, it also acts as a recognizer. And it really gets the mount request for the ext2/ext3 volumes, but system won't assign any mountpoints.

               
              • François Melchior

                So what is missing from Ext2fsd (but also from Ext2ifs and rfsd) to behave like MS IFS drivers (Automatic recognition at boot/at plug and assignments with the Disk Manager)?

                 
              • Nobody/Anonymous

                Perhaps Ext2Fsd should ask MountMgr to assign a mount point...

                 
    • Nobody/Anonymous

      Hi,

      Just downloaded extfsd 0.31a from source forge and installed. Everything working fine, starting like a service, mounting, writing and so on.

      but one thing ;-)

      I did not succeed to find the precise technical information needed to implement the permanent mount of my ext2 partition. I read that your program somewhat tricks the windows mount manager into believing that ext2 is a ntfs (0x07) partition so that it can mount it at boot time and that it keeps the volume data safe.

      So, after each boot, I need to assign it a drive letter..

      Please could you point me the precise page where, step by step, I can safely implement this precious feature?

      Thank you for your help

      roger64 a ubuntu.fr fan

       
    • Nobody/Anonymous

      just a follow up. I found some documentation about it in the author's home page. I have XP

      It seems pretty difficult to understand: just some stumbling points

      - REGEDIT4: I do not find it, I can start regedit
      - Filedisk or filedisk.exe seems equally to be missing
      - "import the  ext2fs.reg (euh?) into your syst. registry": how that?

      Thank you for any help

       
    • Nobody/Anonymous

      still roger64

      I understand that this "permanent feature" existed in previous version (0.31) and has been disabled on 0.31a because sometimes this modified partition could not be mounted on Linux?

      I wonder then, if a just plain script could not do the trick. After booting, I just need about three clicks to add a drive letter to my ext2 partition. This part could be I think be easily automated, though I do not know how to do it. Just a kind of macro. And it would avoid less experienced users -like me-  to try to tweak the registry. My two cents.

       
    • Nobody/Anonymous

      still from roger64

      the question is still standing but maybe not the forum?

       
    • Nobody/Anonymous

      still from roger64

      OK. I close the door. Bye, bye....

       
    • Nobody/Anonymous

      When I use both ext2fsd and ext2ifs, I can assign a permanent mount with ext2ifs' control panel applet, which is fine by me...

       
    • Nobody/Anonymous

      Hi,

      As previous posters, I am happily using extfsd 0.31a, but have to manually assign drive letter at each boot. This is very tedious and I do not want to change partition type to NTFS as this would confuse partition managers and the like.

      Couldn't you make Ext2Mgr.exe assign the drive letter automatically? It would be OK for me that the drive first becomes available at login - its just irritating that it is a manual process at each startup.

      Best regards...

       
    • Matt Wu

      Matt Wu - 2007-12-05

      The best way at the moment to assign a permanent mountpoint is to add a driver letter link into registry, like this:

      [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Session Manager\DOS Devices]
      "X:"="\\Device\\Harddisk0\\Partition2"
      or
      "X:"="\\Device\\HarddiskVolume2"

      Ext2Mgr shows you the device name or volume name. Method 3 of Ext2Mgr's dirver assignment is setting the registry, but the disadvantage is that you must reboot system to make it take into effect.

      Windows MountMgr couldn't keep the MountPoints either, though we could successfully create the MountPoint symlinks via MountMgr ioctls (IOCTL_MOUNTMGR_VOLUME_ARRIVAL_NOTIFICATION, IOCTL_MOUNTMGR_CREATE_POINT). Windows system API SetVolumeMountPoint is also using IOCTL_MOUNTMGR_CREATE_POINT for it's mount purpose. But it could only work with windows-recognized volumes/paritions like ntfs/fat. Previous version of ext2mgr in 0.30 is trying to modify the parition type to fool windows, but Linux grub is fooled too and refuses to boot.

       

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks