GVolume {RGtk2} | R Documentation

## GVolume

### Description

Volume management

### Methods and Functions

`gVolumeGetName(object)`
`gVolumeGetUuid(object)`
`gVolumeGetIcon(object)`
`gVolumeGetDrive(object)`
`gVolumeGetMount(object)`
`gVolumeCanMount(object)`
`gVolumeShouldAutomount(object)`
`gVolumeGetActivationRoot(object)`
`gVolumeMount(object, flags, mount.operation, cancellable = NULL, callback, user.data = NULL)`
`gVolumeMountFinish(object, result, .errwarn = TRUE)`
`gVolumeCanEject(object)`
`gVolumeEject(object, flags = "G_MOUNT_UNMOUNT_NONE", cancellable = NULL, callback, user.data = NULL)`
`gVolumeEjectFinish(object, result, .errwarn = TRUE)`
`gVolumeEjectWithOperation(object, flags, mount.operation, cancellable = NULL, callback, user.data = NULL)`
`gVolumeEjectWithOperationFinish(object, result, .errwarn = TRUE)`
`gVolumeEnumerateIdentifiers(object)`
`gVolumeGetIdentifier(object, kind)`

### Hierarchy

    GInterface
       +----GVolume

### Detailed Description

The `GVolume` interface represents user-visible objects that can be mounted. Note, when porting from GnomeVFS, `GVolume` is the moral equivalent of `GnomeVFSDrive`.

Mounting a `GVolume` instance is an asynchronous operation. For more information about asynchronous operations, see `GAsyncReady` and `GSimpleAsyncReady`. To mount a `GVolume`, first call `gVolumeMount` with (at least) the `GVolume` instance, optionally a `GMountOperation` object and a `GAsyncReadyCallback`.

Typically, one will only want to pass `NULL` for the `GMountOperation` if automounting all volumes when a desktop session starts since it's not desirable to put up a lot of dialogs asking for credentials.

The callback will be fired when the operation has resolved (either with success or failure), and a `GAsyncReady` structure will be passed to the callback. That callback should then call `gVolumeMountFinish` with the `GVolume` instance and the `GAsyncReady` data to see if the operation was completed successfully. If an `error` is present when `gVolumeMountFinish` is called, then it will be filled with any error information.

It is sometimes necessary to directly access the underlying operating system object behind a volume (e.g. for passing a volume to an application via the commandline). For this purpose, GIO allows to obtain an 'identifier' for the volume. There can be different kinds of identifiers, such as Hal UDIs, filesystem labels, traditional Unix devices (e.g. ‘/dev/sda2’), uuids. GIO uses predefind strings as names for the different kinds of identifiers: `G_VOLUME_IDENTIFIER_KIND_HAL_UDI`, `G_VOLUME_IDENTIFIER_KIND_LABEL`, etc. Use `gVolumeGetIdentifier` to obtain an identifier for a volume.

Note that `G_VOLUME_IDENTIFIER_KIND_HAL_UDI` will only be available when the gvfs hal volume monitor is in use. Other volume monitors will generally be able to provide the `G_VOLUME_IDENTIFIER_KIND_UNIX_DEVICE` identifier, which can be used to obtain a hal device by means of `libhalMangerFindDeviceStringMatch()`.

### Structures

`GVolume`

  Opaque mountable volume object.

### Signals

`changed(user.data)`

  Emitted when the volume has been changed.

  `user.data`

    user data set when the signal handler was connected.

`removed(user.data)`

  This signal is emitted when the `GVolume` have been removed. If the recipient is holding references to the object they should release them so the object can be finalized.

  `user.data`

    user data set when the signal handler was connected.

### Author(s)

Derived by RGtkGen from GTK+ documentation

### References

https://developer.gnome.org/gio/stable/GVolume.html

[Package RGtk2 version 2.20.36.3 Index]