Unfortunately the parallel test keeps hitting this bug:
https://bugzilla.redhat.com/show_bug.cgi?id=838081
which could be a bug in the OCaml runtime.
Just test simple mount-local. We will write a parallel test in C to
replace this.
When using tar-in or tools built around it such as virt-make-fs, if
the target filesystem is vfat then unpacking the tarball would fail
because tar tries to chown(2) files and fails.
You would see errors such as:
tar: <file>: Cannot change ownership to uid 500, gid 500: Operation not permitted
This change detects whether the target filesystem supports chown(2).
If not, it adds the --no-same-owner flag to tar to stop it from trying
to change the ownership of newly created files.
Add proper dependencies for these files, but also use 'cmp' to ensure
they only get overwritten if the new files have actually changed, so
we don't rebuild the appliance unnecessarily.
Add xfs_info to show the geometry of the xfs filesystem.
Signed-off-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
RWMJ:
- Updated po/POTFILES.
- Use xfs_ prefix for all struct fields.
- Return uninitialized fields as -1 / empty string.
- Copyedit the description.
case_sensitive_path is undefined when the final path element doesn't
exist. Currently it returns an error, but this means that creating a
new file doesn't work as expected:
$ guestfish --rw -i -d windows touch 'win:c:\blah'
libguestfs: error: case_sensitive_path: blah no file or directory found with this name
We should allow this case (provided there is no trailing slash) so
that new files or directories can be created.
This uses Pod::Simple so it properly parses the input POD and can
generate proper custom output as required specifically by libguestfs.
One immediate benefit is that links between and within manual pages
now work mostly correctly.
By using the once_had_no_optargs flag, this change is backwards
compatible for callers (except Haskell, PHP and GObject as discussed
in earlier commit).
In C, a function called 'func' which has once_had_no_optargs=true will
(because of the previous commit) generate 'func_opts' and a
backwards-compatibility function called 'func'.
This commit changes some of the non-C bindings so that they also
generate 'func_opts' which is merely a wrapper that calls 'func'.
This avoids incompatibility when we rename 'mkfs_opts' etc back to
plain 'mkfs', and it also makes it easier to translate between other
language bindings and C code.
NB: Some bindings do not include aliases:
PHP: There's no way to easily alias methods in PHP < 5.3, and we
can't assume everyone has this minimum version.
GObject: Very complex to add aliases, but we should probably do this
at some point.
Haskell: No support for optargs in these bindings. Unfortunately
this means that we can no longer bind 'Guestfs.add_drive'
(since it will be changed to add optional arguments) making
the Haskell bindings even less useful than they were already.
This commit adds a flag (once_had_no_optargs) which can be used to add
optargs to functions that currently don't have any.
The idea is that if 'func' currently has no optargs, we can safely add
optargs provided we are backwards compatible for existing callers.
In C that means we leave 'guestfs_func' alone and provide an extra
function 'guestfs_func_opts' that takes the optargs ('guestfs_func'
becomes a wrapper that calls 'guestfs_func_opts').
In the C generator this means there are two names for each function
(although the two names are normally identical). 'c_name' is the name
that we export publicly (eg. [guestfs_] 'func_opts'). 'name' is the
internal name of the function (eg. 'func') which is used for
everything apart from the public interface, and also to generate the
no-optargs compat function.
In other languages that can add optional arguments safely, we simply
add the arguments to the existing 'func', so for example in Perl:
$g->func (required_args)
$g->func (required_args, optional_args)
can be used.
Note that this commit does not cause any change to the output of the
generator. I verified this by diffing the output before and after.
For example the existing method:
public void mkfs_opts (String fstype, String device, Map<..> optargs);
is now accompanied by this overloaded method which is a simple wrapper:
public void mkfs_opts (String fstype, String device)
throws LibGuestFSException
{
mkfs_opts (fstype, device, null);
}
This field, which is generated internally by the generator, is the
name of the C function corresponding to each action.
For actions that have NO optional arguments, it's just "guestfs_<name>".
For actions that have any optional arguments, it is
"guestfs_<name>_argv" (since any binding has to construct the optional
argument struct explicitly).
In a future commit, this mapping may become more complex.
This commit also "fixes" the C# bindings which didn't handle optional
arguments properly at all. In fact, it doesn't fix this, it just
changes it enough that it probably now compiles. We should either
compile and test the bindings routinely with Mono, or drop them, since
they are starting to bit-rot.
In the GObject bindings, I have added a space between the C function
name and the first paren.
Apart from the C# and GObject changes, this is just code motion. It
was verified by diffing the output of the generator before and after.
Store the camel-case name directly in the struct instead
of generating it on the fly in only the GObject bindings.
This is just code motion. Tested by verifying that the generator
output is identical.
Each action changes from a tuple like this:
("cat", (RString "content", [Pathname "path"], []), 4,
[ProtocolLimitWarning],
[InitISOFS, Always, TestOutput (
[["cat"; "/known-2"]], "abcdef\n")],
"list the contents of a file",
"[...]");
to a slightly longer but more readable struct:
{ defaults with
name = "cat";
style = RString "content", [Pathname "path"], [];
proc_nr = Some 4;
protocol_limit_warning = true;
tests = [
InitISOFS, Always, TestOutput (
[["cat"; "/known-2"]], "abcdef\n")
];
shortdesc = "list the contents of a file";
longdesc = "[...]" };
["defaults" is a struct which contains the defaults for every field,
allowing us to use the "{ defaults with ... }" syntax to just update
the fields we want to be different from the defaults.]
This is a mechanical change and there is no change to the output of
the generator. I checked the output before and after with diff to
verify this. There are no changes in the output apart from UUIDs
which are expected to change with each run.
