Description
Description:
I encountered an issue in the open
method where, if the combined length of clientId
and theConnection
exceeds the maximum file name length, the directory creation fails silently. This can cause the restoreBackups
function to throw an MqttPersistenceException
.
Steps to Reproduce:
- Pass a
clientId
andtheConnection
whose combined length (after filtering withisSafeChar
) results in akey
exceeding 255 characters. - When the
open
method tries to create a directory with thiskey
, the directory creation fails because the file system's file name length limit is 255 characters.
Impact:
This issue imposes an unintended limitation on MQTT's support for long clientId values, which should normally be supported up to 65,535 characters. It affects the persistence mechanism and could disrupt the normal operation of the library.
Suggested Solutions:
1- Validate key Length: Add a check to ensure that the key length does not exceed 255 characters before creating the directory. If it does, consider truncating the key or using a hashed version to fit within the limit.
2- Handle mkdir Failure: Check the return value of mkdir and throw an appropriate exception if directory creation fails, with a clear error message indicating the cause.
Relevant Code:
Here is the part of the open
function where the issue occurs:
if (!clientDir.exists()) {
clientDir.mkdir(); // Fails silently if the key length exceeds 255 characters
}
And in the restoreBackups
method:
File[] files = dir.listFiles(new PersistanceFileFilter(MESSAGE_BACKUP_FILE_EXTENSION));
if (files == null) {
throw new MqttPersistenceException();
}
However, if the length of the key
exceeds 255 characters, mkdir
fails and does not throw an exception. The directory remains non-existent, causing subsequent calls to listFiles()
in the restoreBackups
method to return null
, which then triggers an MqttPersistenceException
.
Environment:
- Library version: 1.2.5