gparted/include/FS_Info.h

67 lines
2.1 KiB
C
Raw Normal View History

/* Copyright (C) 2008, 2009, 2010 Curtis Gedak
*
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License
* along with this program; if not, see <http://www.gnu.org/licenses/>.
*/
#ifndef GPARTED_FS_INFO_H
#define GPARTED_FS_INFO_H
#include "BlockSpecial.h"
#include <glibmm/ustring.h>
#include <vector>
namespace GParted
{
struct FS_Entry
{
BlockSpecial path;
Glib::ustring type;
Glib::ustring sec_type;
Glib::ustring uuid;
bool have_label;
Glib::ustring label;
};
class FS_Info
{
public:
static void load_cache_for_paths( const std::vector<Glib::ustring> &device_paths );
static Glib::ustring get_fs_type( const Glib::ustring & path );
static Glib::ustring get_label( const Glib::ustring & path, bool & found );
static Glib::ustring get_uuid( const Glib::ustring & path );
static Glib::ustring get_path_by_uuid( const Glib::ustring & uuid );
static Glib::ustring get_path_by_label( const Glib::ustring & label );
private:
static void initialize_if_required();
static void set_commands_found();
static const FS_Entry & get_cache_entry_by_path( const Glib::ustring & path );
Ensure blkid FS_Info cache has entries for all whole disk devices (#771244) More recent versions of blkid don't report an ISO9660 file system on the whole disk device if partitions can be reports for embedded partitions. However when querying the whole disk device directly then the expected ISO9660 file system is reported. For example on CentOS 7 with the previous ISO images: # wget http://git.kernel.org/cgit/utils/util-linux/util-linux.git/plain/tests/ts/isosize/sample.iso.gz # dd if=/dev/zero bs=1M of=/dev/sdc # zcat sample.iso.gz | dd of=/dev/sdc # blkid -v blkid from util-linux 2.23.2 (libblkid 2.23.0, 25-Apr-2013) # blkid | fgrep /dev/sdc /dev/sdc1: UUID="2013-01-04-22-05-45-00" LABEL="ARCH_201301" TYPE="iso9660" PTTYPE="dos" # blkid /dev/sdc /dev/sdc: UUID="2013-01-04-22-05-45-00" LABEL="ARCH_201301" TYPE="iso9660" PTTYPE="dos" # wget http://cdimage.debian.org/debian-cd/8.6.0/amd64/iso-cd/debian-8.6.0-amd64-netinst.iso # dd if=/dev/zero bs=1M of=/dev/sdc # dd if=debian-8.6.0-amd64-netinst.iso bs=1M of=/dev/sdc # blkid | fgrep /dev/sdc /dev/sdc1: UUID="2016-09-17-14-23-48-00" LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660" PTTYPE="dos" /dev/sdc2: SEC_TYPE="msdos" UUID="17F3-1162" TYPE="vfat" # blkid /dev/sdc /dev/sdc: UUID="2016-09-17-14-23-48-00" LABEL="Debian 8.6.0 amd64 1" TYPE="iso9660" PTTYPE="dos" This behavioural difference with blkid is probably as a result of newer versions of udev informing the kernel of the partitions embedded within the ISO9660 image, and not directly as a result of a change in blkid itself. Older distributions don't have partition entries for the above ISO images, but CentOS 7 (with udev 219) and later distributions do have partition entries: # fgrep sdc /proc/partitions 8 16 8388608 sdc 8 17 252928 sdc1 8 18 416 sdc2 Fix by ensuring that the blkid FS_Info cache has entries for whole disk devices, even if each entry has all empty attributes because there is a partition table and not a recognised file system. Calling blkid on whole disk devices containing partition tables produces output like this, with newer versions of blkid: # blkid /dev/sda /dev/sda: PTTYPE="dos" # blkid /dev/sdb /dev/sdb: PTTYPE="gpt" This will be loaded into the FS_Info cache as a blank entry for the device by run_blkid_load_cache(). There will be a path name but all the other attributes will be blank because there are no TYPE, SEC_TYPE, UUID or LABEL name value pairs. With older versions of blkid no output is produced at all. In that case load_fs_info_cache_extra_for_path() will create the same blank entry with just the path name defined. Bug 771244 - gparted does not recognize the iso9660 file system in cloned Ubuntu USB boot drives
2016-12-24 14:58:23 +00:00
static void load_fs_info_cache();
static void load_fs_info_cache_extra_for_path( const Glib::ustring & path );
static bool run_blkid_load_cache( const Glib::ustring & path = "" );
Support /etc/fstab using Unicode labels as mount points (#786502) So far GParted is still loading the default non-reversible encoded labels from blkid in the initial loading of the FS_Info module cache. This encoded label is used to match LABEL=<label> when reading /etc/fstab, via the get_path_by_label() call, so works for ASCII only labels. This prevents GParted enabling the "mount on >" partition menu item when non-ASCII labels are used. To fix this: 1) Stop reading the labels the wrong way. Via the blkid command used to initially load the FS_Info module cache and is subject to default non-reversible encoding of non-printable ASCII bytes. 2) Read all the labels the right way, but only when needed. Only when /etc/fstab file contains LABEL=<label> and get_path_by_label() is called, read all the labels from blkid without encoding them via run_blkid_update_cache_one_label(). 3) Return label from the cache. get_label() returns the cached label, loading it into the cache first if needed with run_blkid_update_cache_one_label(). In the worst case scenario of having a LABEL=<label> in /etc/fstab blkid will be run for every partition containing a recognised file system to read the label. On my desktop with 5 hard drives, 4 SWRaid arrays and 31 recognised file systems running 'blkid -o value -s LABEL ...' 31 times took 0.074 seconds of a total scan time of 9.072 seconds. Less that 1% of the total scanning time. When LABEL=<label> is not used in /etc/fstab individual blkid executions are only used to read labels for file systems where there is no file system specific tool available reducing the impact further. Blkid itself caches the data in it's blkid.tab cache file rather than reading all file systems on each invocation. Also the Linux file system cache will already contain the blkid executable file, needed libraries files and the blkid.tab cache file itself. Hence why repeated execution of blkid is so fast. Further to the updated comment in set_partition_label_and_uuid(). Matching LABEL=<label> from /etc/fstab uses the label obtained from blkid run in the C locale so this kind of assumes it returns the label correctly and it does for my limited testing on Unicode enabled desktops. Just not sure if it would be true for all cases in all locales compared to the FS specific command run in the users default locale. Bug 786502 - Support reading Unicode labels when file system specific tools aren't available
2017-08-28 09:52:44 +00:00
static void update_fs_info_cache_all_labels();
static bool run_blkid_update_cache_one_label( FS_Entry & fs_entry );
static bool fs_info_cache_initialized ;
static bool blkid_found ;
Workaround older blkid not distinguishing between FAT16 and FAT32 (#743181) Older versions of blkid don't correctly distinguish between FAT16 and FAT32 file systems when overwriting one with the other. This effects GParted too with these file systems on whole disk devices where only blkid is used to recognise the contents. See previous fix for why only blkid is used in this case: Avoid whole disk FAT being detected as MSDOS partition table (#743181) Example: # blkid -v blkid from util-linux 2.20.1 (liblkid 2.20.0, 19-Oct-2011) # mkdosfs -F16 -I /dev/md1 # blkid | fgrep md1 /dev/md1: SEC_TYPE="msdos" UUID="7C23-95D9" TYPE="vfat" # mkdosfs -F32 -I /dev/md1 # blkid | fgrep md1 /dev/md1: SEC_TYPE="msdos" UUID="7F93-98F4" TYPE="vfat" So blkid recognised the UUID changed but didn't remove the SEC_TYPE for the FAT32 file system. See FS_Info::get_fs_type() as it uses this to distinguish between FAT16 and FAT32. This is a caching update bug in blkid, because telling blkid not to use the cache gets the right results: # blkid -c /dev/null | fgrep md1 /dev/md1: UUID="7F93-98F4" TYPE="vfat" With testing determined that blkid from util-linux 2.23 and later are not affected and earlier versions are affected. Mostly recently known affected distribution is Ubuntu 14.04 LTS with util-linux 2.20.1. The straight forward fix would be to instruct blkid to not use its cache with 'blkid -c /dev/null'. But using blkid's cache is needed to prevent blkid hanging for minutes when trying to access a non-existent floppy drive when the BIOS is set incorrectly. See commit: 18f863151c82934fe0a980853cc3deb1e439bec2 Fix long scan problem when BIOS floppy setting incorrect Instead, when using an older affected version of blkid and when blkid cache reports a vfat file system, run blkid again bypassing the cache. The device is known to exist and contain a vfat file system, just not whether it is a FAT16 or FAT32 file system, so can't be a non-existent floppy device and won't hang. Bug 743181 - Add unpartitioned drive read-write support
2015-03-08 11:13:20 +00:00
static bool need_blkid_vfat_cache_update_workaround;
static std::vector<FS_Entry> fs_info_cache;
};
}//GParted
#endif /* GPARTED_FS_INFO_H */