Hi Pali,

With the steps mentioned in the initial post I think that the GNU/Linux OS will simply treat the file "/tmp/fat" as a file, and not as a device.

To have the file treated by the OS as a device, a loop device is needed.

For example the above steps would become:

$ truncate -s 100M /tmp/fat
$ sudo losetup /dev/loop0 /tmp/fat
$ sudo mkfs.vfat /dev/loop0
$ sudo ./src/gpartedbin /dev/loop0


In this example the commands to remove the device are:

$ sudo losetup -d /dev/loop0
$ rm /tmp/fat


Curtis

I know how to use loop device. But accessing file image as ordinary file is easier as it does not require root access.

What file system images do you expect to support compared to all the
ones GParted recognises, including LVM PV, SWRaid, LUKS?

Do you expect any modification operations to work?  E.g.  Label,
new UUID, even reformat or resize?

You suggest a non-root user could run gpartedbin.  That says to me you
never actually tried it.

> What file system images do you expect to support

I worked with FAT and UDF and both with this patch worked.

> Do you expect any modification operations to work?  E.g.  Label,
new UUID, even reformat or resize?

Label, UUID and reformat worked. resize for obvious reason would not work, as size is fixed.

> You suggest a non-root user could run gpartedbin.  That says to me you
never actually tried it.

It is working fine for me. I just run whole shell, or just gpartedbin in fakeroot (it LD_PRELOAD library which overwrites some libc functions which then returns e.g. for getuid() --> 0). Whole process is running in original user (there is no escalation), just gparted thinks user is root. Until it has permissions for particular files (e.g. for disk images owned by current user), everything is working fine.

I'm using this setup for development, as it is better idea to not develop under root user, specially tool which access hard disks.

Created attachment 359535 [details] [review]
Detect named file system image files (v2)

Here's version 2 of your patch.

The only coding difference is the addition of a call to
initialize_if_required() at the start of the new method
FS_Info::load_cache_for_paths().

It also updates a comment and the commit message.

I have only tested for correct detection of file system images.  Tested
on CentOS 6, Ubuntu 16.04 LTS And Fedora 26.  Works as expected except
for the following:

1) btrfs - No file system usage
   Reason: btrfs command doesn't work with file system images, only
   block devices.
      # btrfs filesystem show /dev/sdc23
      Label: 'test-btrfs'  uuid:8c010dfb-2733-465d-aeb9-bb14069af7ec
              Total devices 1 FS bytes used 112.00KiB
              devid    1 size 256.00MiB used 88.00MiB path /dev/sdc23
      # cat /dev/sdc23 > /tmp/btrfs.img
      # btrfs filesystem show /tmp/btrfs.img
      Error: not a valid btrfs filesystem: /tmp/btrfs.img

2) lvm2 pv - No file system usage
   Reason: Ultimately LVM2 only works with block devices.
      # lvm pvs /dev/sdc26
        PV         VG Fmt  Attr PSize   PFree
        /dev/sdc26    lvm2 ---  256.00m 256.00m
      # cat /dev/sdc26 > /tmp/lvm2_pv.img
      # lvm pvs /tmp/lvm2_pv.img
        Failed to find device for physical volume "/tmp/lvm2_pv.img".

These content specific issues won't be worked around.  Neither will we
document in the GParted Manual that fact that GParted can work with file
system image files.

I intend to commit this in the next day or so, unless you see any reason
not to.

I'm fine with it.

The following patch as been pushed upstream ready for inclusion in the
next release of GParted.

Make sure that FS_Info cache is loaded for all named paths (#787181)
https://git.gnome.org/browse/gparted/commit/?id=e8f0504b13d98e23e70021f70638184daab228ec

This enhancement was included in the GParted 0.30.0 release on October 10, 2017.