Category: Bard

WordPress backup (BackWPup) WARNING File name is too long to save correctly in TarGz archive – tar and zip file name limits explored

While attempting to backup WordPress, I noticed that a warning was being shown.
This warning stated that “WARNING: File name wp-content/uploads/… is too long to be save correctly in TarGz archive”.
The warning seems clear enough, but how long exactly is “too long”, and can this be improved upon?

Searching online gave a few examples of people with similar issues:

The consensus on fixing this seems to be to use “zip” instead.
This is also the officially provided solution for this: WARNING: FILE NAME TOO LONG TO BE SAVED

OK, if you don’t care about any further details, this is the solution. Use “zip”.
I was interested as to the limitations of tar and zip, and if they could be improved upon, so I asked through Bard AI with an appropriate prompt shown below:

===

When creating a backup with tar.gz, I sometimes get a file name too long warning. It seems that only 100 character file names are supported. Is this 100-character limit something that applies to all available tar executables? Is there a way to allow longer file names? Does this limitation differ by Linux, Windows, or Linux distribution/version?

===
The 100-character limit on file names in tar archives is a limitation of the original tar format, which was defined in 1979. This format is still used by many tar implementations today, including the default format used by the GNU tar command.

However, there are also a number of tar implementations that support longer file names. One example is GNU tar with the --format=gnu option. This format allows for file names of up to 255 characters.

Another option is to use a different archive format altogether. For example, the zip format supports file names of up to 65535 characters.

Whether or not you can use longer file names in a tar archive will depend on the tar implementation that you are using and the format of the archive.

To answer your specific questions:

  • The 100-character limit on file names does not apply to all available tar executables. There are a number of tar implementations that support longer file names.
  • There are a few ways to allow longer file names in a tar archive. One option is to use the GNU tar command with the --format=gnu option. Another option is to use a different archive format altogether, such as zip.
  • The limitation on file name length in tar archives does not differ by Linux, Windows, or Linux distribution/version. It is a limitation of the original tar format, which is used by many tar implementations on all platforms.

If you are creating a tar archive, and you get a file name too long warning, you can try one of the following:

  • Use a tar implementation that supports longer file names, such as GNU tar with the --format=gnu option.
  • Use a different archive format altogether, such as zip.
  • Rename the files with longer names to shorter names.
  • Split the files with longer names into multiple files with shorter names.

===

The important parts from above are:
  • tar file name character limit is 100 by default
  • –format=gnu option makes the file name character limit 255
  • zip file name character limit is 65535
OK, so from this it can be concluded that zip file names can be long enough for all but extreme cases.
100 characters is definitely very small, so is an issue.
255 is still not very large, so zip definitely is safer.
I asked AI again if there was a way to increase the character limit further for tar, but it stated there was no way to do this. Maybe there is, but even if, it probably isn’t easy to do, so use zip seems like the way to go.

List of known/common standardized JSON Schema properties.

The JSON Schema standard is extensive and descriptive, but it can lead to taking too much time to quickly find the name of a property, etc.
I decided to generate a list of important JSON Schema properties so they can be easy to find when needed.
The following was generated using Bard AI, and seems to be accurate.

—

Please provide a list of all known standardized properties in jsonschema with the property name, followed by a colon + space delimiter, and the followed by a description of the property. Each should be on one new line.

—
The following is a list of all known standardized properties in JSON Schema, with the property name, followed by a colon + space delimiter, and then followed by a description of the property, each on a new line:

  • $schema: The URI of the JSON Schema version used to define the schema.
  • $ref: A reference to another JSON Schema that defines the schema for this object.
  • $id: A unique identifier for the schema.
  • title: A human-readable title for the schema.
  • description: A human-readable description of the schema.
  • type: The data type of the value that the schema validates.
  • enum: An array of valid values for the schema.
  • const: A constant value that the schema validates.
  • multipleOf: A number that the value must be divisible by.
  • maximum: The maximum value that the schema validates.
  • exclusiveMaximum: A boolean value indicating whether the maximum value is exclusive or inclusive.
  • minimum: The minimum value that the schema validates.
  • exclusiveMinimum: A boolean value indicating whether the minimum value is exclusive or inclusive.
  • maxLength: The maximum length of a string that the schema validates.
  • minLength: The minimum length of a string that the schema validates.
  • pattern: A regular expression that the value must match.
  • maxItems: The maximum number of items in an array that the schema validates.
  • minItems: The minimum number of items in an array that the schema validates.
  • uniqueItems: A boolean value indicating whether the items in an array must be unique.
  • maxProperties: The maximum number of properties in an object that the schema validates.
  • minProperties: The minimum number of properties in an object that the schema validates.
  • required: An array of property names that must be present in an object that the schema validates.
  • dependentRequired: An object mapping property names to arrays of property names. If a property that is present in the first array is present in the object, then all of the properties in the second array must also be present.
  • additionalProperties: A boolean value indicating whether additional properties are allowed in an object that the schema validates.
  • properties: An object mapping property names to JSON Schemas that define the schemas for those properties.
  • patternProperties: An object mapping regular expressions to JSON Schemas that define the schemas for properties that match those regular expressions.
  • allOf: An array of JSON Schemas that the value must validate against.
  • anyOf: An array of JSON Schemas that the value must validate against at least one of.
  • oneOf: An array of JSON Schemas that the value must validate against exactly one of.
  • not: A JSON Schema that the value must not validate against.

Please note that this list is not exhaustive, and there may be other standardized properties in JSON Schema that are not listed here.
—

 

How to create a valid definitions only jsonschema file?

Sometimes it is useful to group jsonschema to be referenced elsewhere when desired like a utility module but for schema.
However, it is a little confusing on how to group these definitions.
There is also the issue of making sure the schema is still valid because jsonschema libraries that handle things such as validation may not accept custom formats.

I asked Bard AI, and got an appropriate response, so I have shared the information below:

I want to create a jsonschema file that only contains definitions(jsonschema that can be referenced).
I don’t need the root object to be a usable schema.
I want the file to be a valid jsonschema.

Is this possible, and please provide an example.

—

Yes, it is possible to create a JSON schema file that only contains definitions. This is a perfectly valid way to use JSON schema, and it can be useful for organizing your schemas and making them more reusable.

Here is an example of a JSON schema file that only contains definitions:

JSON
{
  "$schema": "http://json-schema.org/draft/2020-12/schema",
  "definitions": {
    "MediaObject": {
      "type": "object",
      "required": ["type", "url"],
      "properties": {
        "type": {
          "type": "string",
          "enum": ["image/jpeg", "image/png"]
        },
        "url": {
          "type": "string",
          "format": "uri"
        }
      }
    },
    "Person": {
      "type": "object",
      "required": ["name", "age"],
      "properties": {
        "name": {
          "type": "string"
        },
        "age": {
          "type": "integer"
        }
      }
    }
  }
}

This schema file defines two schemas: MediaObject and Person. These schemas can then be referenced from other schema files using the $ref keyword.

For example, the following schema file references the MediaObject and Person schemas defined in the previous example:

JSON
{
  "$schema": "http://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": ["mediaObject", "person"],
  "properties": {
    "mediaObject": {
      "$ref": "#/components/schemas/MediaObject"
    },
    "person": {
      "$ref": "#/components/schemas/Person"
    }
  },
  "components": {
    "schemas": {
      "MediaObject": {
        "$ref": "#/definitions/MediaObject"
      },
      "Person": {
        "$ref": "#/definitions/Person"
      }
    }
  }
}

This schema file is valid, even though the root object is not a usable schema. This is because the root object is only used to define the MediaObject and Person schemas, which can then be referenced from other schema files.

You can use this approach to create a library of reusable schema definitions. This can make your schemas more modular and easier to maintain.

—

I was reading the jsonschema specification draft, and noticed that the “$defs” property was used to group definitions. I have noticed you and others have used the “definitions” property to group definitions. Which one is better, and why?

The $defs keyword was introduced in JSON Schema draft 2019-09. It is a newer and more standardized way to group definitions.

The definitions keyword is still valid, but it is deprecated. It is recommended that new schemas use the $defs keyword instead.

There are a few reasons why the $defs keyword is better:

  • It is more standardized. The definitions keyword was not defined in the JSON Schema specification, but was rather a convention that was widely used. The $defs keyword is defined in the JSON Schema specification, so it is more likely to be supported by all JSON schema implementations.
  • It is more explicit. The definitions keyword could be used for other purposes in addition to grouping definitions. For example, it could be used to define a set of named anchors for use in JSON Pointer expressions. The $defs keyword is specifically for grouping definitions, so it is more explicit and less likely to be confused with other features of JSON Schema.
  • It is more future-proof. The JSON Schema specification is still under development, and it is possible that the definitions keyword could be deprecated in the future. The $defs keyword is a newer keyword, so it is more likely to be supported in the future.

Overall, the $defs keyword is the better choice for grouping definitions in JSON Schema. It is more standardized, more explicit, and more future-proof.

However, it is important to note that the definitions keyword is still valid, and there are many existing JSON schemas that use it. If you are working with an existing JSON schema that uses the definitions keyword, there is no need to change it to use the $defs keyword.

—

As stated, if the root schema only provides the definitions, then it is valid, and although the “definitions” property is often used for grouping definitions, it has actually been standardized to be “$defs” instead, but definitions is still valid and has been used from before the property was standardized.

When the URL of an iframe is changed within the iframe, the iframe element’s “src” attribute does not change. What is the reasoning for this?

I asked Bard AI about why iframes don’t update the src attribute when the content changes, and got a very logical response.

Thinking about it, one obvious point is that the content within the iframe should not leak any data in the page. This is because in the iframe, the content may include something like an OAuth login, or query state. It is possible that the query parameters could contain something like an OAuth code or sensitive search queries, which should definitely not be shared with the parent DOM.

The full response is below.
—

There are a few reasons why the iframe element’s src attribute does not change when the URL of an iframe is changed within the iframe.

First, it is important to remember that an iframe is a separate document from the parent document. When you change the URL of an iframe within the iframe, you are actually changing the URL of the embedded document, not the iframe element itself.

Second, the src attribute of an iframe element is read-only. This means that once the src attribute is set, it cannot be changed.

Finally, there is a security risk associated with allowing iframes to change their own src attribute. If an iframe were able to change its own src attribute, it could potentially load malicious content from a different domain.

To avoid these problems, if you need to change the URL of an iframe, you must do so from the parent document. You can do this using JavaScript to set the src attribute of the iframe element.

Here is an example of how to change the URL of an iframe using JavaScript:

JavaScript
// Get the iframe element
var iframe = document.getElementById('myIframe');

// Set the src attribute of the iframe element
iframe.src = 'https://new-url.com';

When you set the src attribute of an iframe element using JavaScript, the iframe will be reloaded with the new URL.

It is important to note that you can only change the URL of an iframe if the iframe is from the same domain as the parent document. If the iframe is from a different domain, you will need to use a cross-origin resource sharing (CORS) request to change the URL of the iframe.

Testing political spectrum ranking of key political people in Bard AI

ChatGPT has been getting most of the attention for AI text generation.
However, I do find Bard AI to be helpful with many questions, and has been generally quite fair so far.
To really test how biased Bard AI is, I decided to test the political spectrum of varying key political people such as political commentators and actual politicians.
The results are below.

From most left wing to right wing, how would you rank the following people: Carl Benjamin, Peter Hitchens, Donald Trump, Adolf Hitler.

Here is a ranking of the people you listed, from most left wing to most right wing:

Carl Benjamin (also known as Sargon of Akkad) is a British YouTuber and political commentator who is generally considered to be on the left of the political spectrum. He has been critical of both the left and the right, but he has generally been more sympathetic to left-wing causes such as social justice and environmental protection.

Peter Hitchens is a British journalist and author who is generally considered to be on the right of the political spectrum. He is a social conservative who opposes abortion, same-sex marriage, and euthanasia. He is also a fiscal conservative who supports low taxes and free markets.

Donald Trump is the 45th and current president of the United States. He is a Republican who is generally considered to be on the right of the political spectrum. He is a populist who has promised to “Make America Great Again.” He has been critical of both the left and the right, but he has generally been more sympathetic to right-wing causes such as immigration restriction and trade protectionism.

Adolf Hitler was the leader of the Nazi Party and chancellor of Germany from 1933 to 1945. He was responsible for the Holocaust, in which six million Jews were killed. He is widely considered to be one of the most evil people in history.

It is important to note that these are just generalizations, and there is a great deal of variation within each political ideology. For example, there are both left-wing and right-wing libertarians. Additionally, people’s political views can change over time.

—
This wasn’t too bad. I thought it would go a little harsher on Carl Benjamin and Donald Trump, especially with all the mainstream smearing that AI is likely to be trained on.
As usual, the standard Adolf Hitler, Holocaust, six million, evil… which I suppose can not be avoided at this point so I’ll let it pass.
I decided to try again but focus more on the left of the political spectrum.
—

Do these same but with the following people: Joe Biden, Hasan Piker, Carl Benjamin, Peter Hitchens, Ash Sarkar, Joe Rogan.

Sure. Here is a ranking of the people you listed, from most left wing to most right wing, based on their publicly expressed views:

  • Hasan Piker is a Turkish-American Twitch streamer and political commentator who is a member of the Democratic Socialists of America. He is a self-described socialist who supports policies such as universal healthcare, free college, and a $15 minimum wage.
  • Joe Biden is the 46th and current president of the United States. He is a member of the Democratic Party and is considered to be a moderate Democrat. He supports policies such as expanding access to healthcare, investing in clean energy, and raising the minimum wage.
  • Carl Benjamin (also known as Sargon of Akkad) is a British YouTuber and political commentator who is generally considered to be on the left of the political spectrum. He has been critical of both the left and the right, but he has generally been more sympathetic to left-wing causes such as social justice and environmental protection.
  • Ash Sarkar is a British journalist and political commentator who is a member of the Socialist Workers Party. She is a self-described socialist who supports policies such as the abolition of capitalism, the abolition of the police, and the abolition of borders.
  • Peter Hitchens is a British journalist and author who is generally considered to be on the right of the political spectrum. He is a social conservative who opposes abortion, same-sex marriage, and euthanasia. He is also a fiscal conservative who supports low taxes and free markets.
  • Joe Rogan is an American comedian, podcast host, and UFC commentator. He is generally considered to be a libertarian, although he has expressed support for a variety of political views. He is known for his willingness to interview people from all sides of the political spectrum.

It is important to note that these are just generalizations, and there is a great deal of variation within each political ideology. For example, there are both left-wing and right-wing libertarians. Additionally, people’s political views can change over time.

—
This was a little more surprising.
Joe Rogan as the most right wing? A libertarian pot-smoking comedian doesn’t seem very right wing. I would have thought that Mr Hitchens would be considered more right wing.
It is also a little strange that a “self-described socialist” Ash Sarkar would be considered more right wing than Carl Benjamin.

There is the possibility that AI is just messing up the idea of ranking properly, but AI is very likely to become a more and more prominent part of deciding what is true and what is false, and so I do think this is something people should pay a lot of attention to.
—

How to parse the datetime format used on lines in phperror.log?

The following was returned using Bard AI. It provided a good response, so I am sharing below:

Prompt used: “For the $format argument used in DateTime::createFromFormat of PHP, what format should I use to parse “10-Sep-2023 00:13:12 UTC”?”.

The following format can be used to parse the string 10-Sep-2023 00:13:12 UTC using the DateTime::createFromFormat function in PHP:

$format = 'd-M-Y H:i:s T';

This format specifies the following:

  • d: The day of the month, as a two-digit number.
  • M: The month, as a three-letter abbreviation.
  • Y: The year, as a four-digit number.
  • H: The hour, as a two-digit number in 24-hour format.
  • i: The minute, as a two-digit number.
  • s: The second, as a two-digit number.
  • T: The time zone, as a single-letter abbreviation.

In this case, the time zone is UTC, which is the Coordinated Universal Time.

To parse the string 10-Sep-2023 00:13:12 UTC, we can use the following code:

PHP
$dateTime = DateTime::createFromFormat($format, '10-Sep-2023 00:13:12 UTC');
Use code with caution. Learn more

content_copy

This will create a DateTime object representing the specified date and time in UTC.

We can then use the DateTime object to get the individual components of the date and time, or to perform other operations, such as formatting the date and time in a different format.