I'm on it.

thanks for reporting.

*** Bug 329970 has been marked as a duplicate of this bug. ***

*** Bug 329859 has been marked as a duplicate of this bug. ***

the problem with this is, we actually need an universal way to deal with automounting. Simply disabling one DE's automounter wouldn't help much if you use another automount system.

Right now it seems best to do a quick unmount as soon as gparted detects a mount during an operation. Although this may seem a bit hacky it could provide an universal solution to this problem.

Any opinions?

Well, i have found that gnome-volume-properties is to be turned off, and then there is no more auto mount on fedora core 5 /gnome !
But i had to make it by hand

Created attachment 62473 [details]
creation failed : mounted volume !

Yes that 's it : I have enable the automount and the bug is back

The problem only comes with usb, and maybe with livecd where GParted is run !
I gonna try now !

no problem at all with SLAX. I have run GParted from slax ; all the partition are automounted by slax at boot. Running GParted i create the partition i want on a hdd, and there is no automount run during the creation. 
Everything sounds good to me :)

The nly problem comes with usb.

thanks for testing LarryT! :)

It seems pmount is going to rescue us, from the manpage:
--------------------------------------------------------------
Some applications like CD burners modify a raw device which must not be mounted while the burning process is in progress. To prevent automatic mounting, pmount offers a locking mechanism:  pmount --lock   device pid will prevent the pmounting of  device until it is unlocked again using  pmount --unlock   device pid.
---------------------------------------------------------------------------

I'll add and test it asap

Hi,

There is a rudimentary solution in CVS. It still needs some love, but at least it seems to be working. I'd appreciate it if you could grab it from CVS and do some testing.

thanks!

tested on FC5 : there is no "pmount" on FC5 !
test aborted !
The only workaround is to manually disable the automount which is very easy and fast :)

ok, since it seems pmount isn't as widely used as i thought, i decided to fall back om HAL properties (storage.automount_enabled_hint). This approach works even better because it allows you to disable automounting on an entire device (instead of per partition).

It works for me, but doesn't for larry_T.
@Larry: please ping me when you have time to do some live debugging.
@Jeroen: please get the latest CVS and do some testing. If getting it from CVS is a problem i can provide a tarball.

you can use this tarball for testing:
http://gparted.sourceforge.net/gparted-cvs20060404.tar.bz2

about the :
LARRY's SPECIAL VERSION ;-)
libparted : 1.6.25
automounting disabled


in fact it doesn't work.
Maybe we should have a special version for Fedora ?
Adding anything  to disable gnome-volume-information ???
(dont understand what i say :p)

Hi Larry,

Im still not sure if your problem is related to HAL or to the fact unmount doesn't seem to work on your machine (#337218).
Anyway, the current disabling of automount is official ( http://webcvs.freedesktop.org/*checkout*/hal/hal/doc/spec/hal-spec.html?rev=1.83 , grep for 'automount' ) and it works OK for all ( 3 ;) ) testers.

The funny part is that i set exact the same property as gnome-volume-properties does and this seems to work for you :)

For now i'd like to see if it works for most people (i've just release 0.2.4) and try to solve your unmount problems in #337218 .

Hi Plors,

Thanks for supplying the tarball, but getting the source shouldn't be a probem; compiling is :). I'm downloading gparted build-dep's right now to see if it compiles on Ubuntu. I'll keep you posted!

Jeroen.

The good news is that compilation went flawless. 'apt-get build-deb gparted', './configure' and 'make' resulted in a new gparted executable. Note that garted build-depends on libparted-1.6-dev, but I assume libparted is not an issue here.

The bad news is that the gnome-volume-manager still kicks in after the first partition is created. I'll attach the gparted error log. Note that this log says creating the filesystem fails because it already contains a file system. Where did that file system come from? (The mounted filesystem works fine)

Created attachment 62764 [details]
Gparted error details from CVS-20060404

I experimented a bit further, and noticed the following:

1. It seems gnome-volume-manager kicks in right after the partition type is set. 
2. It only happens if I create a partition at the very beginnning of the disk.
3. The partition's filetype cannot be determined by gparted, but it is mounted as vfat.
4. Unmounting it and trying to format it as another filesystem filas due to (1).

Hope this helps debugging...

maybe it has something to do with the fact gparted is started as root and the hal property is set by root.
I think i have to ask this on a hal mailinglist or channel.

i'm only wondering why it does work for me and a few other testers (we all use the udev/dbus/hal/g-v-m combi) and doesn't for you guys.

send an email to the hal mailinglist a couple of hours ago, still waiting for a reply. 

I'll keep you posted.

*** Bug 337218 has been marked as a duplicate of this bug. ***

'fixed' by adding a file
/usr/share/hal/fdi/policy/gparted-disable-automount.fdi
with contents:

<deviceinfo version='0.2'>
<device>
<match key='@block.storage_device:storage.hotpluggable' bool='true'>
<merge key='volume.ignore' type='bool'>true</merge>
</match>
</device>
</deviceinfo>

while gparted is running. This seems to work quite well, although i would like
to have a cleaner solution. Anyone any ideas?

ok, i know that LarryT tested it and found it works for him. Jeroen, did you run any tests using the latest CVS ?

No, I didn't run any tetst lately, as I'm kinda in between houses. Internet access should be restored in about a week (I'm posting this from work). But this patch is so trivial, I'll give it a try this weekend.
And just to be usre: I can use the default Dapper Drake version of gparted and try this fix, right? Or did you add something in CVS as well?

hmmz, not sure. This has only been in CVS for about 2 weeks and i don't know if drake contains stuff that fresh?

anyway, It's indeed trivial, so if testing is a problem to you i'm happy to just close this bug.

*** Bug 353887 has been marked as a duplicate of this bug. ***

ok, last monday we released gparted-0.3 which contains this fix. Should be easy to test now you can just grab an official release.

please report back if possible.

Well, I finally tested it this weekend with an older version of gparted. Manually adding the file worked like a charm, so I suppose this will work also when the file is added by gparted. Thanks for fixing!

I've tested 0.3 and it appears to work properly.

cool, thanks for testing. It's nice to finally close this bug :)

I'd like to express a concern about this:  What happens if gparted crashes for some reason?  Will this file be left on the system?  If so, wouldn't g-v-m mysteriously stop working?

Thanks,
Andrew

Yep, i even experienced this once. According to some info on the hal list there is no nicer way to do this atm, but newer version of HAL will provide a better way of doing this.
I'm gladly proven wrong here btw!! :)

Anyway, this code still contains a FIXME and it will remain there till we've found a better way for doing this.

*** Bug 376999 has been marked as a duplicate of this bug. ***

*** Bug 379215 has been marked as a duplicate of this bug. ***

Hi,

I'd like to add some extra information. /usr/share/hal/fdi/policy/gparted-disable-automount.fdi file cause some problems as you suspected before. Sometimes it remains there even GParted is not running anymore. Because of this file, HAL doesn't automount USB devices properly.

There are similar bug reports in both Fedora's and Pardus's bug tracking systems (I know there is a FIXME in the code, I just wanted to imply that it really needs to be fixed ;)).

FYI.


Thanks,

Do you know anything about a better solution? I'm more than willing to fix this, but i don't have time to investigate it myself.

(In reply to comment #37)
> Do you know anything about a better solution? I'm more than willing to fix
> this, but i don't have time to investigate it myself.

Unfortunatelly I don't have neither. I decided to apply a patch to HAL's start-up script in Pardus for an extra check like this:

(...)
if os.path.exists("/usr/share/hal/fdi/policy/gparted-disable-automount.fdi"):
    os.remove("/usr/share/hal/fdi/policy/gparted-disable-automount.fdi")
(...)

I know how it looks like but even if something goes wrong with GParted users should be able to get their USB devices automatically mounted, at least in their subsequent sessions. And of course this is a 'dirty distribution way' to get rid of the risk and it can't be considered as a permenant solution for GParted at all. 

OTOH I can't blame your solution that much -I think there must be a more reliable interface in *HAL* to do this properly. And I guess it comes to your comment #33 again :)


Best wishes,

However, it would be a tad better to not set volume.ignore, but storage.automount_enabled_hint. That way, the icons at least appear on the desktop and the user can mount them manually. With volume.ignore, nothing happens at all.

Created attachment 96448 [details] [review]
Ubuntu patch

FYI, I just applied this patch to the Ubuntu package:
    - Install a signal handler for cleaning up the automount disabling FDI, so
      that it will be cleaned up on program crashes, too.
    - Use storage.automount_enabled_hint instead of volume.ignore for the
      automount disabling FDI. That way, the new drives will at least appear
      in Gnome and the user can mount them manually.

Reopening bug since I believe that my patch is much more robust. Please consider applying it.

I will try as soon as I have one minute left

Martin,

Thank you very much for the patch.  After some preliminary testing it appears to be a good solution to removing the "/usr/share/hal/fdi/policy/gparted-disable-automount.fdi" on program crashes.

I have applied this patch to the new SourceForge repository (http://gparted.sourceforge.net/svn.php).  The svn.gnome.org repository is not available for write access to the two new developers of gparted (Laurent and myself).

Regards,
Curtis Gedak

Starting from hal-0.5.9, hal itself offers a better way of handling the issue here without writing any fdi policy file on system. The trick (which we've been using on Fedora for almost a year now [1]) is to use a helper script to start gparted as;

#!/bin/bash
/usr/bin/hal-lock --interface org.freedesktop.Hal.Device.Storage  --exclusive --run /usr/sbin/gparted



[1]. http://cvs.fedoraproject.org/viewcvs/devel/gparted/

Re-Opening Bug.

After pondering the problem of preventing automounting, I believe that
the better solution is to use the hal-lock program (as suggested by
Deji Akingunola comment #44) .  My reasons for this are as follows:

1) Risk of Leaving .fdi File on Filesystem.

   With the creation of the .fdi file
   (/usr/share/hal/fdi/policy/gparted-disable-automount.fdi), there is
   always a slim change that it will not be removed by GParted.  This
   is because even with a signal handler to cleanup the .fdi file,
   something abnormal such as a power outage may terminate GParted,
   and leave the file in the filesystem.  This will prevent future
   device automounting in GNOME and would be difficult to track down
   for a user.  This is not a nice side-effect.

2) Future GParted and Parted Lock Conflict.
 
   GParted uses GNU libparted to detect and manipulate devices and
   partition tables.  As such, it makes more sense that Parted (and
   hence libparted) should handle the locking.  Also, I can foresee a
   future conflict if GParted acquired the lock, and then called
   libparted to perform an operation.  If libparted was expecting to
   acquire the lock, it would fail since GParted already had the lock.

3) KDE 3.5.8 Appears to Ignore Both hal-lock and .fdi File.

   Testing with (k)ubuntu 7.10 Gutsy Gibbon has shown me that neither
   the hal-lock program, nor the .fdi file prevent KDE from prompting
   the user with a dialog box with device mount options.  Hence
   neither of these solutions appears to work for KDE.  The hal-lock
   solution is preferable though since it has less side-effects (see
   point 1 above).  Also if hal-lock were to be detrimental to KDE,
   it could more easily be implemented on GNOME desktops only.

In conclusion, unless a better method of preventing automounting is
known, the best course of action for the time being is to remove the
.fdi create/delete functionality from GParted, and instead recommend
that GNOME desktops call hal-lock to run GParted.


Any opinions?

*** Bug 491109 has been marked as a duplicate of this bug. ***

*** Bug 445515 has been marked as a duplicate of this bug. ***

Finally addressed this bug using hal-lock as outlined in comment #45.  Thank you to Deji Akingunola for the hal-lock idea.

The fix involved renaming the gparted executable to gpartedbin, and then creating a shell script named gparted to invoke hal-lock which in turn invokes gpartedbin. 

The previous code which dealt with handling the gparted-disable-automount.fdi file has been removed.

This update has been committed to the Gnome repository for inclusion with the next release of GParted currently planned for the end of April, 2008.

Since gparted now depends on HAL, please add a configure time check and some documentation so downstream maintainers can update dependencies.

Thank you for the comment Arun.  A check for hal-lock has been added to configure.in, and a note about the requirement for hal-lock has been added to the README file.

As Gilles mentions in a Gentoo Bug (http://bugs.gentoo.org/show_bug.cgi?id=22045), it makes more sense to just check for the existence of hal-lock in gparted.in. If it exists, HAL probably exists and will do an auto-mount. If it doesn't, the hal-lock really isn't required anyway.

Thank you for your suggestion Arun.  Your logic makes sense to me.  I will work on changing it.

By the way, the gentoo bug you referenced does not appear to relate to gparted.

(In reply to comment #52)
[...]
> By the way, the gentoo bug you referenced does not appear to relate to gparted.

Whoops -- missed one digit. http://bugs.gentoo.org/show_bug.cgi?id=220459

Ah, that link looks much better.  :-)

Do you have a recommendation on how to search if 'hal-lock' is available?

My first thought is to check whether anything is returned by `which hal-lock`.
If something is returned, then hal-lock exists on the system.
Else hal-lock is not available in the PATH.

The absolute requirement for hal-lock has been removed.  GParted will now work on systems with or without hal-lock.

This change has been committed to the Gnome repository for inclusion in the next release of GParted.

*** Bug 541372 has been marked as a duplicate of this bug. ***

I am much surprised to see this bug marked as resolved...
I just experienced it when resizing a partition on a USB disk. I'm using Ubuntu Intrepid (8.10).

Apparently, I am not the only one:
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/37768

I am not *at all* a specialist of HAL, but shouldn't hal-lock lock  org.freedeskdesktop.Hal.Device.Volume in addition to or instead of org.freedeskdesktop.Hal.Device.Storage? It seems that the mount/unmount functionality are on the former...

Hi Pierre-Antoine,

Thank you for this update.  This is indeed a frustrating problem.

As far as I know, GParted is doing the right think by acquiring an exclusive lock on org.freedeskdesktop.Hal.Device.Storage.  This is aligned with the HAL 0.5.10 specification which states that a lock on the org.freedeskdesktop.Hal.Device.Storage is sufficient to stop mounting and unmounting.

Quote from:
http://people.freedesktop.org/~david/hal-spec/hal-spec.html#interface-device-volume

--- begin quote ---
If a volume originates from a storage device (and all volumes do), it also is checked whether the caller is locked out of the org.freedesktop.Hal.Device.Storage interface of the originating storage device. As a corollary, it is sufficient to just either a) lock the storage device; or b) globally lock the org.freedesktop.Hal.Device.Storage  interface if one wants to lock out callers from mounting volumes from either a specific drive or all drives.
--- end quote ---

Perhaps some auto mount processes are not honouring this statement in the HAL specification?

(In reply to comment #58)
> Hi Pierre-Antoine,
...
> 
> Perhaps some auto mount processes are not honouring this statement in the HAL
> specification?
> 
I would think so too. And my first guess is the gnome-mount program. There have been a couple of bug-reports about this in Fedora too.

Oops, my bad.  It turns out I had a typo in the lock name.  ;-(

See bug #571347

I will see about creating a new release of GParted soon.

The fix for the spelling mistake in the lock name has been included in the recently released GParted 0.4.3

Hi, I'm experiencing similar problem with GParted 0.5.1 on Ubuntu 10.4.
I start from an unformatted SD card (the problem is present also with usb).
a) I create a first partition on it by GParted
b) I leave GParted open and I browse the new partition (Menu->Places->"New 
   Partition Created") then it is automounted; (the automount isn't locked)
c) The partition is still editable in GParted; it seems I can modify them,
   but if I try I receive an error:
   ..........
     create new ext2 file system  00:00:00    ( ERROR )
     	
     mkfs.ext2 -L "" /dev/mmcblk0p1
     	
     mke2fs 1.41.11 (14-Mar-2010)
     /dev/mmcblk0p1 is mounted; will not make a filesystem here!
...........
   and (annoying) the filesystem on partition results unknown

Thanks for support

Thank you Salvatore for taking the time to lookup and add to this bug report.

Normally we would re-open the bug report, but in this case I think the problem lies elsewhere, perhaps in Ubuntu's version of hal or by the Ubuntu automounter ignoring the exclusive lock taken by GParted.

Following is my reasoning in thinking that GParted is doing the right thing.


1)  It would appear that Ubuntu 10.04 is using hal 0.5.14-0ubuntu5 based on the following link:
http://packages.ubuntu.com/lucid/hal


2)  From reviewing the hal 0.5.14 specification it would appear that partition editors can use hal-lock to prevent automounting.

Quote from hal 0.5.14 specification:
http://people.freedesktop.org/~dkukawka/hal-spec-git/hal-spec.html#locking-guidelines

---------- begin quote ----------
Guidelines

Locking is only useful if applications requiring exclusive access actually use the locking primitives to cooperate with other applications. Here is a list of guidelines.

    * Disk Management / Partitioning

      In order to prevent HAL-based automounters from mounting partitions that are being prepared, applications that access block devices directly (and pokes the kernel to reload the partitioning table) should lock out automounters by either a) obtaining the org.freedesktop.Hal.Device.Storage lock on each drive being processed; or b) obtaintaing the global org.freedesktop.Hal.Device.Storage lock. This includes programs like fdisk, gparted, parted and operating system installers. See also the section called “org.freedesktop.Hal.Device.Volume interface” and the hal-lock(1) program and manual page. 
---------- end quote ----------


3)  The man page for hal-lock indicates the following method for obtaining an exclusive lock:

Quote from "man hal-lock" on Ubuntu 10.04

---------- begin quote ----------
NOTES
       This program is only useful for launching software that doesn't use HAL
       at all (since such software launched using hal-lock would be locked out
       itself);  for example a partition table editor part-foo may use wrapper
       script like this

       hal-lock  --interface  org.freedesktop.Hal.Device.Storage   --exclusive
       --run /path/to/part-foo-program
---------- end quote ----------


4)  The GParted code does indeed use hal-lock in this manner to invoke gparted as can be seen in the gparted shell script file usually installed in either /usr/sbin/gparted or /usr/local/sbin/gparted.

       hal-lock --interface org.freedesktop.Hal.Device.Storage --exclusive \
               --run "$BASE_CMD"

Refer to the bottom of the following source code file:
http://git.gnome.org/browse/gparted/tree/gparted.in


In conclusion I believe that GParted has done it's part to abide by the hal guidelines to prevent automounting of file systems.  This leads me to believe that the problem lies elsewhere with another program that is not following the hal guidelines.

Perhaps you could raise this problem with the Ubuntu team?

Copy of two email messages from Raimund Andersen due to problems posting to bugzilla:


---------- Begin Email Message 1 ----------
Hello Curtis,

sorry for addressing you directly, atm there seems to be a problem between the bugzilla interface and my email-provider.

I just read through all this bug messages regarding hal, and I am wondering if gparted is prepared for the coming absence of hal. Myself, I updated my gentoo system to gnome 2.30 and removed all the hal dependencys from my system.
First, automount stopped working. But then I read something about udisks, (http://www.freedesktop.org/wiki/Software/udisks), and after installing that, gnome got it's automount behavior back as it worked before.
I expect all distros will go a way like this in near future.

To prevent automounting with udisks, there seems to be the 'inhibit' option:

   --inhibit-all-polling [-- program arg ...]
       Inhibits polling on all devices. If no program is given, polling is
       inhibited until Ctrl+C is pressed. Otherwise the program is spawned
       and the polling is only inhibited until the program terminates.

If this is already implemented in gparted, please forget about this mail,
but otherwise it should be worth to keep an eye on udisks (or whatever might come after/next to it).

Best regards,

Raimund
---------- End Email Message 1 ----------

---------- Begin Email Message 2 ----------
update:

I just tested the behaviour by using an USB-Flash stick, and I can confirm that automounting does occur during a gparted session. 

However, starting gparted with "udisks --inhibit  /usr/sbin/gparted", no automounting takes place, so thats probably a good solution.

rgds,

Raimund
---------- End Email Message 2 ----------

Raimund,

Thank you for your interest in GParted.  The current code uses "devkit-disks --inhibit /path-to-gparted" to invoke gparted on systems that no longer use hal, and instead use devicekit-disks.

For more information on this enhancement, please refer to the following bug report:
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/428133


From a quick search on devkit-disks, it would appear that this has been renamed to udisks on December 1st, 2009.
http://www.freedesktop.org/wiki/Software/DeviceKit-disks

Thank you for bringing this to my attention.  I will look into adding this new name into the logic for invoking gparted.

Regards,
Curtis Gedak

A fix for devkit-disks being renamed to udisks has been committed to the git repository for inclusion in the next release of GParted (0.6.0).

The relevant commit can be viewed at the following link:
http://git.gnome.org/browse/gparted/commit/?id=4168794e8e80d2d6457d87f33983cee2d836f527

Salvatore,

It appears that Ubuntu 10.04 uses udisks so this patch will be required.

Salvatore,

I have created a bug report on Ubuntu's launchpad regarding this problem and the patch to resolve the issue.

Automounting not prevented with GParted in Ubuntu 10.04
https://bugs.launchpad.net/ubuntu/+source/gparted/+bug/588530

Dear Curtis,

thank you very much for the bug report you created on launchpad Ubuntu and for the patch.
I understand that the problem it was a little incompatibility of Ubuntu 10.4 and GParted and I say thank you for resolving it.
My limited linux expertise gone me unable to test the patch; I tried to rename the file gparted.in to gparted.sh and launch it, but it doesn't work. When the patch will be available as package, I will try it and I will communicate you the results.


Thanks again,

Salvatore Reale