You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Seeing a few issues with MTP if you want to physically remove a device and re-insert a different one:
Calling only MTP.send_StoreRemovedEvent() and MTP.send_StoreAddedEvent(), like MTP_SD_Callback does, is very inadequate. All it does is send events to the host without notifying MTPStorage, so all the previously indexed content from the previous card remains and gets reused for the new card...
There's no method on the main MTP object to completely remove a filesystem. There is MTPStorage.removeFilesystem() so you can do MTP.storage()->removeFilesystem(x) but you need the store id for that.
The index file is by default created on the first storage object. Bad Things Happen if that storage object goes away.
MTPStorage.file_ may be left open from a previous operation by the host. The next time OpenFileByIndex is called, it will try to close file_ and may blow up because the filesystem that the File uses no longer exists / has been replaced. This is especially obvious when the "old" SD card is FAT16/FAT32 and gets replaced by an EXFAT card, because the FAT/EXFAT volumes have very different structure but occupy the same memory in the SD object.
It's also a bit annoying that MTPStorage has a public method to register a class loop callback, but the fstype parameter (for this function, MTP.addFilesystem and several others) is an enum - meaning it's limited to the values already defined in the header rather than user-defined custom values. So if a user wants to add their own filesystem types with loop callbacks, they have to hijack one of the pre-defined values...
The text was updated successfully, but these errors were encountered:
Seeing a few issues with MTP if you want to physically remove a device and re-insert a different one:
It's also a bit annoying that MTPStorage has a public method to register a class loop callback, but the fstype parameter (for this function, MTP.addFilesystem and several others) is an enum - meaning it's limited to the values already defined in the header rather than user-defined custom values. So if a user wants to add their own filesystem types with loop callbacks, they have to hijack one of the pre-defined values...
The text was updated successfully, but these errors were encountered: