RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Description of problem:
for zero device, it reported as "data" for file api, but in el7, it reported as "\0", which not quite make sense, 
 actually, it should reply the below result, 
 
 file.c:do_file(),
 
 623       free (buf);
 624 
 625       if (S_ISDIR (statbuf.st_mode))
 626         ret = strdup ("directory");
 627       else if (S_ISCHR (statbuf.st_mode))
 628         ret = strdup ("character device");
 629       else if (S_ISBLK (statbuf.st_mode))
 630         ret = strdup ("block device");
 631       else if (S_ISFIFO (statbuf.st_mode))
 632         ret = strdup ("FIFO");
 633       else if (S_ISLNK (statbuf.st_mode))
 634         ret = strdup ("symbolic link");
 635       else if (S_ISSOCK (statbuf.st_mode))
 636         ret = strdup ("socket");
 637       else
 638         ret = strdup ("unknown, not regular file");


Version-Release number of selected component (if applicable):
libguestfs-1.17.43-1.el7.x86_64

How reproducible:
always

Steps to Reproduce:
1.guestfish -N fs zero-device /dev/vda : file /dev/vda
2.
3.
  
Actual results:
it reported zero device as "\0" for file api

Expected results:



Additional info:

I've noticed this too.  It's a bug (or change?) in the regular
'file(1)' command:

  $ truncate -s 100k data
  $ file data
  data: \0

Note that libguestfs doesn't define the output of the
guestfs_file function.  It says in the documentation:

  The output depends on the output of the underlying file(1) command and
  it can change in future in ways beyond our control.  In other words,
  the output is not guaranteed by the ABI.

If you want to check if a file contains zeroes, use
guestfs_is_zero instead.

file 5.11 prints:

MAGIC=magic/magic ./src/file /tmp/data 
/tmp/data: data

The version of file in Fedora 17 is 5.10, which is older than
upstream, so I think it just needs an update.