I ran into this incredibly frustrating issue while generating some CSV files for GPT Assistants : a 0 kb file had been created, and when trying to delete, it failed with a windows error message reporting that the file didn’t exist :

The file properties didn’t look odd, except for the 0 Kb size, and the missing extension :

After testing some command lines with “del”, trying to rename the file, move it, delete the whole folder using third party tools like Total Commander, the only thing that worked was that command line to remove the whole folder :

rd /s "\\?\d:\code\xml2csv\target\test-classes"

And eventually, I found the issue : the problematic filename was generated automatically by an app, and contained invalid characters : “Code civil – Titre préliminaire : De la publication, des effets et de l’application des lois en général.csv”, which were responsible of the invalid file state. The filename was displayed only up to the “:”.

While trying to publish a new version of my fork of mysql-backup4j, the release of the latest version failed with error “Event: Failed: Repository Writable”, whether I tried to publish using “mvn deploy” (whatever the value of the autoReleaseAfterClose setting), or from the nexus repository manager portal.

The maven “mvn deploy” command returned the following error

[ERROR]
[ERROR] Nexus Staging Rules Failure Report
[ERROR] ==================================
[ERROR]
[ERROR] Repository "frneolegal-1040" failures
[ERROR]   Rule "RepositoryWritePolicy" failures
[ERROR]     * Artifact updating: Repository ='releases:Releases' does not allow updating artifact='/fr/neolegal/mysql-backup4j/1.2.3/mysql-backup4j-1.2.3.jar'

While the Nexus Repository manager displayed this one

Once identified, the issue was kind of obvious. My maven “target” folder hadn’t been cleaned prior to the compilation, and the artefacts of the previous version were still present. The deploy operation was pushing the new and old artefacts, triggering a release failure, since the previous version had already been released.

Deleting the “target” folder manually – or even better using the “mvn clean” command – solved the issue. And to prevent any future occurence, just use the following maven command :

mvn clean deploy

Let’s say you have a Ms Office 365 “Support” group, whose emails are managed by your tech support. You need to create emails folders and rules to organize your Support mailbox. Yet, nowhere is a menu to Create these folders in Outlook.

It came to me as a surprise, but this feature is not supported by default. However, as a Ms 365 admin, you can partially enable it, provided that your users rely only on Outlook Web Access (OWA), and not on the Outlook desktop application, because the group folders will on be visible on the web version of Outlook.

Microsoft documented the procedure here. In brief, you’ll have to use PowerShell to :

1. Enable folders and rules creation, using :
   Set-OrganizationConfig -IsGroupFoldersAndRulesEnabled $true
2. Authorize folders and rules creation, using :
   Set-OrganizationConfig -IsGroupMemberAllowedToEditContent $true

But if you are Ms 365 newbie, like me, you may have to first setup your powershell environment. Here is the complete – summarized – sequence :

1. Ensure your Ms Office 365 account is an admin account
2. On your Windows Machine, run PowerShell as an administrator, so that you’ll be able to Install the Exchange Online Powershell module (as documented by Microsoft here), and run the following commands.
3. Install-Module -Name PSWSMan
4. Install-Module -Name ExchangeOnlineManagement
5. Update-Module -Name ExchangeOnlineManagement
6. Import-Module ExchangeOnlineManagement;
7. Connect-ExchangeOnline -UserPrincipalName <your_user_name>
8. Set-OrganizationConfig -IsGroupFoldersAndRulesEnabled $true
9. Set-OrganizationConfig -IsGroupMemberAllowedToEditContent $true

Once the configuration modified, there’s a delay for the change to be taken into account. You may immediately see the “Create subfolder” menu appear when right clicking on your group in OWA, yet you may get a “Permission denied” error for a while. However, after half an hour, I was able to create and view Group folders, but only in OWA, as documented by Microsoft.

While starting a SpringBoot/JHipster MariaDB application, I ran into this Liquibase database update error:

liquibase.exception.MigrationFailedException: Migration failed for changeset config/liquibase/changelog/00000000000000_initial_schema.xml

This was not a fresh database initialization, but an upgrade of an existing databse wich was recently moved to a new MariaDB server. Yet the error pointed to the initialization changeset.

The issue came from the liquibase change log tables, named DATABASECHANGELOG and DATABASECHANGELOGLOCK, uppercase. Our database naming convention required lower case table names, hence the conversion to lower case of the liquibase change log table names. On the previous MariaDB Server, table names where case insensitive, this was not the case anymore on the new server, leading to the creation by Liquibase of two empty DATABASECHANGELOG and DATABASECHANGELOGLOCK tables, next to the databasechangelog and databasechangeloglock existing ones. Consequence: Liquibase was trying to initialize an already initialized database.

Here are three ways to solve this problem

Option 1 : Switch back to Liquibase default change log table names

That may not be elegant, but switching back to the default Liquibase change log table names will fix the issue, and prevent similar future issues. For example, when using SpringBoot, I had to rename the tables in two places : in the SpringBoot “application.yml” file, and in the Maven “pom.xml” file. That wouldn’t have been required would I have stuck to the default table names.

Option 2 : Disable case sensitivity for MariaDB table names

Changing the database configuration ensures that you won’t encounter the issue with any Liquibase application. However, when ever you change server you’ll have to enable this setting, and this may be an issue in the unlikely case where a database has two tables with the same name but different case.

The MariaDB ‘lower_case_table_names’ setting in my.cnf enables table name case insensitivity, by forcing all table names to be lowercase. To check if it’s enabled, use :

SHOW GLOBAL VARIABLES LIKE ‘lower_case_table_names’;

SHOW GLOBAL VARIABLES LIKE 'lower_case_table_names';

If ‘lower_case_table_names’ = 0, follow this procedure to change the parameter value in the MariaDB configuration files :

[mariadb]
lower_case_table_names=1

Option 3 : Specify Liquibase change log table names in SpringBoot application.properties file

Eventually, you can specify your Liquibase change log table names in your application.properties or application.yml file, as explained here, using the spring.liquibase.database-change-log-lock-table and spring.liquibase.database-change-log-table properties.

For example, in an application.yml file :

spring:
  liquibase:
    database-change-log-lock-table: 'databasechangeloglock'
    database-change-log-table: 'databasechangelog'