Teensyduino File System Integration, including MTP and MSC

Odd Windows doesn't seem to have a way to R/W ext4.
Search shows some tools to read only or one to converts ext4 partition to Fat32 or NTFS

So funny that Teensy can do ext4 I/O ... ???

You will probably need to use a virtual Linux machine like mysys2 or mingw to format an SD card USB device to ext4 on Windows.

EDIT: Some free programs to format a device to ext4 in Windows:

https://www.diskpart.com/articles/format-ext4-windows-7201.html

https://www.diskgenius.com/how-to/format-ext4-windows.php
 
Last edited:
You will probably need to use a virtual Linux machine like mysys2 or mingw to format an SD card USB device to ext4 on Windows.

EDIT: Some free programs to format a device to ext4 in Windows:

https://www.diskpart.com/articles/format-ext4-windows-7201.html

https://www.diskgenius.com/how-to/format-ext4-windows.php

Sounds Like fun. Probably need to look through the code more, as I wonder if you have anything derived from FS or File ...

If so it would be fun to see how hard it would be to talk to it with MTP ;)
 
@defragster - Your welcome. Curious to see if they work well. @KurtE - I am still putting the pieces of this puzzle together. It's really low level code. So far most of the basic file op's are there. Things like getting the size of a file is a bit of a challenge as you have to open the file for read, seek to the end of the file get the file position and then close the file. This is not an uncommon way to get the file size. You could use the stat or fstat command which is in libc but it looks like that is not implemented in the Teensy toolchain. It also requires writing code for the _stat() function. All of the time and date functions are there, access to file and directory attributes, getting and setting ownership. Ext4 also supports hardlinks and symlinks which is kinda cool.

Getting setup to be able to integrate into FS is where I am headed at the moment. Like LittleFS was, it's different than a Windows style file system.

Sounds like @Paul could use more testers for Arduino 2.0. I'm going to give a whirl:)

EDIT: I use UBUNTU and the Mate desktop as well. Mate is very much like the original Gnome desktop.
 
Last edited:
@defragster - Your welcome. Curious to see if they work well. @KurtE - I am still putting the pieces of this puzzle together. It's really low level code. So far most of the basic file op's are there. Things like getting the size of a file is a bit of a challenge as you have to open the file for read, seek to the end of the file get the file position and then close the file. This is not an uncommon way to get the file size. You could use the stat or fstat command which is in libc but it looks like that is not implemented in the Teensy toolchain. It also requires writing code for the _stat() function. All of the time and date functions are there, access to file and directory attributes, getting and setting ownership. Ext4 also supports hardlinks and symlinks which is kinda cool.

Getting setup to be able to integrate into FS is where I am headed at the moment. Like LittleFS was, it's different than a Windows style file system.

Sounds like @Paul could use more testers for Arduino 2.0. I'm going to give a whirl:)

EDIT: I use UBUNTU and the Mate desktop as well. Mate is very much like the original Gnome desktop.

Just a note I have been using EaseUS Partition Master which formats for ext3 and ext4. There is a free version although not sure what limitations there is: https://www.easeus.com/partition-manager/epm-free.html?x-clickref=1100lvTpwQVf

Just getting use to Ubuntu Mate since that is the version I am using on my PI4. Rather like it since its set up to be more like Windows :)
 
Just a note I have been using EaseUS Partition Master which formats for ext3 and ext4. There is a free version although not sure what limitations there is: https://www.easeus.com/partition-manager/epm-free.html?x-clickref=1100lvTpwQVf

Just getting use to Ubuntu Mate since that is the version I am using on my PI4. Rather like it since its set up to be more like Windows :)

I'm with you on that. That is why I like Mate as well. The regular Ubuntu desktop with the side bar is a little to busy for me...
 
Will give EaseUS P.M. a look. Have the Pro edition and just running it now to move a HDD to a SSD.
Not planning to jump on Ext4 right away given I have no linux boxes active.

Still have a few things on the plate before getting into ext4. Since I get so focused on an issue I can't let it go until I get it working. Sure no one else is that way :)
 
Post #1 not updated: TD 1.57 b3(+) and MAIN BRANCH >> github.com/KurtE/MTP_Teensy

This 'user post' having an issue not repro when test case added to MakeFiles, suggested use of LFS PROGRAM for storage of mtpindex.dat file.

Problem is an SD card with over 490 files.
My issue is that running MTP_Teensy Example_3_simple_SD.ino, Windows Explorer view of the Portable Device shows only ~60 of the 490+ files. Same result for PC-side app built in C# with MediaDevices package.

Tested with updated MakeFiles.ino: https://github.com/Defragster/T4LockBeta/tree/main/MakeFiles

'r' writes 490 files of 48 bytes each to drive root.

Using IDE 1.8.19 and TD 1.57b3 on T_4.1 builtin SD card using 128GB SD.

NOTE: If mtpindex.dat is a problem when it resides on SD media, and fix not expected, and the use of the LFS Program storage disk is needed: if there isn't an example, there probably should be?

ALSO: saw a post that "LFS" File Open/write/close is much slower than back a couple in TD 1.54?
forum.pjrc.com/threads/70467-LittleFS-performance-issue-for-QSPI-flash-from-1-54-beta10-to-1-56
> ADDED: 'o' >> a timed test simulation of that to MakeFiles.ino ... using supplied code in that post

Testing with NOR Flash on T_4.1:
Code:
Menu Options:
	t - Test Files write 2204
	b - Test Files write BIG
	s - Test Files write small
	u - Test Files write USER edit
	n - Test ASCII and UTF8 Filenames
[B]	r - Root files - make Many
	o - OpenWriteClose timed test
[/B]	v - Verify Files
	l - List files on media

	R - Restart Teensy
	U - USB reset
	W - Remove ALL media content
	C - Copy LFS media content to SD

[B]Completed 100 open/write/close in a total of ... 17418 ms - avg tx/ms = 174
Per Tx in Micros:  Avg open: 4585    Avg print: 167033    Avg close: 2565
[/B]
----	Task 'o' complete!	----

Choose LFS test Media with edit to:
Code:
#define USE_SDIO_SD
//#define USE_PSRAM
//#define TEST_QSPI // Typical NOR FLASH
//#define TEST_QSPI_NAND // NAND Flash
 
Last edited:
UPDATE - based on sleep and post in the 'fail to enumerate thread':

Repeated test without LFS Program disk for mtpindex.dat storage and the old DIR and data confusion seems to be improved?

Reading Kurt's post#7 suggested the LFS Prog disk isn't needed - which I didn't try at 4 AM ...

Just rebuilt with: //#define LFS_MTPINDEX
That removes the LFS Program disk for mtp index file.

Using current MTP code from KurtE's github there is no file confusion or dir mixups with 783 files in 21 folders and 13.6 MB of disk data!
> Makefiles wrote the files on SD
> MTP drive mounted and ALL copied to PC HDD
> Pull SD card to PC and copy all files to PC HDD
> File compare shows all files transferred ( one error to post on the MTP/MSC thread )
> This includes 490 root files just added that display fine in Windows explorer

>> This looks like one 512 Byte block was lost: 32 lines of 16 Bytes. :: 32==0x98ef2-0x98ed2

RE: that test there was one file miscompare in the files copied to PC with MTP versus that direct from SD card used:
FileCopyError.png
Where the error is this dropped file segment:
CopyError.png
 
Playing with MakeFiles.ino ROOT files count 490 - wondering if their size of 48 was too small - bumped to 992 and renamed so they would trigger content size during Verify.

To see it work ( Files that Verify are NOT listed doing a Verify_DIR - only those with Errors : and those not named to trigger verify )

But to get that I did a RENAME on the PC MTP interface and a 'v'erify then showed this DEBUG OUTPUT that confused me:
Code:
/992_Mrt  4.txt
/990_Mrt  4.txt
> this is the only debug output I've seen in 'Release' build

ANyhow the size bump didn't result in any issues in Windows File Explorer display of 490 root files - plus all the other folders where test files are stored.
 
Last edited:
QUESTION: With recent code there was a better way to RESTART MTP to catch Teensy side changes?

Currently MakeFiles offers this:
Code:
      case 'U': // USB Reset
#if defined(USB_MTPDISK) || defined(USB_MTPDISK_SERIAL)
        usb_init();  // shuts down USB if already started, then restarts
#endif

<edit>: Uploaded current MakeFiles.ino at github link : Changed Device name to 2206 from 2204 for file set reference and compare.

NOTE: Redid a CLEAN SD fill with 'r', 't', 'b' ( root files, test files, big files )
> copied via MTP from Win 11 explorer
> pulled SD card and placed copy on HDD and Code Compare found ONE similar data loss as above - same file folder - diff file and now 1088 bytes missing?
View attachment 28689

Doing disk SCAN shows errors found:
Code:
G:\>dir FOUND.000
 Volume in drive G is ExFat116GB
 Volume Serial Number is C815-F826

 Directory of G:\FOUND.000

06/14/2022  02:58 PM           393,216 FILE0000.CHK
06/14/2022  02:58 PM           524,288 FILE0001.CHK
06/14/2022  02:58 PM           131,072 FILE0002.CHK

Here is a ZIP of the Corrupt file data recovered - they are large - but perhaps Telling as to where they come from?:
View attachment FILE0001.chk.zip

Just confirmed those FOUND.000 files were NEW as they are removed by 'W'ipe the Teensy makefiles.ino does:
Code:
  Removed DIR>	4K/
	Removed>	mtpindex.dat
	Removed>	System Volume Information/WPSettings.dat
	Removed>	System Volume Information/IndexerVolumeGuid
  Removed DIR>	System Volume Information/
	Removed>	FOUND.000/FILE0000.chk.txt
	Removed>	FOUND.000/FILE0001.chk.txt
	Removed>	FOUND.000/FILE0002.chk.txt
  Removed DIR>	FOUND.000/
Doesn't mean they were not remains from the delete.
 
Last edited:
SD card corruption follow up. <EDIT>: This SD card is formatted ExFAT

Emptied drive with "W"ipe
> PC found no errors but added the 'Sys Vol Info" folder back
SD into MakeFiles.ino
> 'r', 't', 'b'
SD returned to PC - NO CORRUPTION

SD returned to T_4.1 MTP
> MTP file copy all files to PC HDD
> SD returned to PC, All files copied to HDD

SCANDISK then CMD>Chkdsk /F:
Code:
G:\>dir FOUND.000
 Volume in drive G is ExFat116GB
 Volume Serial Number is C815-F826

 Directory of G:\FOUND.000

06/14/2022  03:49 PM           131,072 FILE0000.CHK

So SD corruption seems to occur during the MTP transfer?

SD Drive was not checked before copy to HDD? Not seeing how that read files should cause corruption.
View attachment FILE0000.chk.txt
Here is that chk file renamed with txt - is that an image of the mtpindex.dat file or other?

<EDIT> Forgot SD to MTP copy file compare.
ONE FILE IN ERROR: D:\tmp\TD_1.57\14June_MTP\D0.60\64512_563.txt

Missing data here:
Code:
zE. 563x  607E5
zE. 563x  607E6
 [B][COLOR="#FF0000"]  >> // This data block is not on the copy using MTP[/COLOR][/B]
zE. 563x  60827
zE. 563x  60828
 
Last edited:
Flipping the copy direction: Blank SD in T_4.1 running MakeFiles.ino fill from PC MTP

MTP Explorer in Win 11 select All Files copied from last MakeFiles.ino create copied to the PC from the SD card: 14.2 MB in 1540 files and 40 folders

SD card starts empty and freshly ExFat formatted by official SD card tool, All files copy with no errors or warnings - the LFS Program disk is not in use for the index file.

> On T_4.1 'v'erify finds no problems with file content
> return SD card to PC and put files onto HDD and do File Compare: ALL files Identical!

SD Drive Properties / Tools / CHECK - ERRORS FOUND AGAIN! - this is a diff 64GB SD card freshly formatted with updated SD Card Formatter:
Code:
 Directory of G:\FOUND.000
06/14/2022  06:32 PM           131,072 FILE0000.chk.txt

File extension .TXT added to view file and uploaded here:View attachment FILE0000.chk.txt


So it seems the Teensy management of the mtpindex.dat file is somehow problematic? Perhaps it is left open when the SD card is removed?
 
@All - I found some good examples of lwext4 usage. This is the link:
https://github.com/autoas/as/tree/master/com/as.infrastructure/system/fs/vfs

Basically a virtual file system using lwext4. I just need to create a standard interface layer that we can use with FS. Things like a peek() function will have to be done from scratch. It also has an example of using a stat() function that can be used to get a file size and file mode (isdir etc...). Going to work on it this weekend...
 
Pushed Update to github.com/Defragster/T4LockBeta/tree/main/MakeFiles

Added LFS options for:
Code:
	F - Format Disk Low Level
	S - SAFE Unused block Format

The main write loop of the Verifiable data will exit on 'disk full' first failure ( that can take 12-23 seconds on the NOR Flash just tested !!! ), so looping for multiple files won't HANG for extended periods after first failure.

This can happen if the media at hand it not large enough for the chosen 'add file' operation. {t,b,s,u,r}

Also the us timing on each file write was cleaned up to show elapsed on each one. There are LONG BLIPS at times, probably when the LFS 'cache' of unused blocks gets rebuilt.
Also added elapsed us shown for each file removed.

Here is what disk full failure on 16 MB Flash looks like: Normal 992B writes taking 180 or 149 ms, on 'not enough space' file is SHORT and noted as wrong and that takes 12.3 seconds to return! It quits the loop and then detects and reports 'DISK FULL?' when free space less than 2048 bytes:
Code:
	File size=992=992	 us=180281    end:zR. 482x   8D21
	File size=992=992	 us=149683    end:zR. 483x   8D5D
	File size=992=256	 [B][COLOR="#FF0000"]us=12326547[/COLOR][/B]    end: >> WRONG << zR. 484x   8D99

----	Task 'r' complete!	----

 DISK FULL?

Did a "W"ipe and retry and it took 29.4 seconds on Failed out of space write: File size=992=256 us=29471482 end: >> WRONG
 
Last edited:
An experiment update...

I have mentioned in past that there are issues with the Index file setup, if for example the first FS added is for SD and there is no SD file or it is Read only or...
You do have the option of creating a RAM disk and add that first, but that is sort of messy if you really don't want a ramdisk to show up...

So wondered about creating a Memory Filesystem, sort of like my BogusFS and sort of like Frank's Memory file stuff, although different as, weill I allocate the
buffer or reallocate if if needed...

I put the code up in a new branch to play with: https://github.com/KurtE/MTP_Teensy/tree/Index_file_memory_fs

And I currently enable this by: MTP.useFileSystemIndexFileStore(MTPStorage::INDEX_STORE_MEM_FILE);

Which is in the SD_MTP_debug.ino sketch which I also pushed up...
This is the one that was using to debug the 490+ file issue...

There are still debug messages and the like I need to fix and remove.

Also may play with. If we fail to open the Initial index on the default Storage (first FS added), then have it fallback to this code...

I left in the code that shows when it malloc or realloc... For T4.x it uses the extended malloc code to allow it to go to PSRAM by default...

Ran it with the 490+ file case.
Code:
cannot open Index file
$$$ Failed to seek for write Index record: 0 addr:0 Cur: 0
	$$0x2020f390 = malloc(2048)
	$$0x2020f390 = realloc(0x2020f390, 4096)
	$$0x2020f390 = realloc(0x2020f390, 6144)
	$$0x2020f390 = realloc(0x2020f390, 8192)
	$$0x2020f390 = realloc(0x2020f390, 10240)
	$$0x2020f390 = realloc(0x2020f390, 12288)
	$$0x2020f390 = realloc(0x2020f390, 14336)
	$$0x2020f390 = realloc(0x2020f390, 16384)
	$$0x2020f390 = realloc(0x2020f390, 18432)

Dump Storage list(1)
store:0 storage:10001 name:SD Card fs:20000ed8

Dump Index List
0: 0 1 1 65535 0 530 0 0 /
16: 0 0 0 0 0 48 1655278820 1655278820 Mrt_  1.txt
17: 0 0 0 0 16 48 1655278820 1655278820 Mrt_  2.txt
18: 0 0 0 0 17 48 1655278820 1655278820 Mrt_  3.txt
19: 0 0 0 0 18 48 1655278820 1655278820 Mrt_  4.txt
20: 0 0 0 0 19 48 1655278820 1655278820 Mrt_  5.txt
21: 0 0 0 0 20 48 1655278820 1655278820 Mrt_  6.txt
22: 0 0 0 0 21 48 1655278820 1655278820 Mrt_  7.txt
23: 0 0 0 0 22 48 1655278820 1655278820 Mrt_  8.txt
24: 0 0 0 0 23 48 1655278820 1655278820 Mrt_  9.txt
25: 0 0 0 0 24 48 1655278820 1655278820 Mrt_ 10.txt
26: 0 0 0 0 25 48 1655278820 1655278820 Mrt_ 11.txt
27: 0 0 0 0 26 48 1655278820 1655278820 Mrt_ 12.txt
28: 0 0 0 0 27 48 1655278820 1655278820 Mrt_ 13.txt
29: 0 0 0 0 28 48 1655278820 1655278820 Mrt_ 14.txt
30: 0 0 0 0 29 48 1655278820 1655278820 Mrt_ 15.txt
31: 0 0 0 0 30 48 1655278820 1655278820 Mrt_ 16.txt
32: 0 0 0 0 31 48 1655278820 1655278820 Mrt_ 17.txt
33: 0 0 0 0 32 48 1655278820 1655278820 Mrt_ 18.txt
34: 0 0 0 0 33 48 1655278820 1655278820 Mrt_ 19.txt
35: 0 0 0 0 34 48 1655278820 1655278820 Mrt_ 20.txt
36: 0 0 0 0 35 48 1655278820 1655278820 Mrt_ 21.txt
37: 0 0 0 0 36 48 1655278820 1655278820 Mrt_ 22.txt
38: 0 0 0 0 37 48 1655278820 1655278820 Mrt_ 23.txt
39: 0 0 0 0 38 48 1655278820 1655278820 Mrt_ 24.txt
40: 0 0 0 0 39 48 1655278820 1655278820 Mrt_ 25.txt
41: 0 0 0 0 40 48 1655278820 1655278820 Mrt_ 26.txt
42: 0 0 0 0 41 48 1655278820 1655278820 Mrt_ 27.txt
43: 0 0 0 0 42 48 1655278820 1655278820 Mrt_ 28.txt
44: 0 0 0 0 43 48 1655278820 1655278820 Mrt_ 29.txt
45: 0 0 0 0 44 48 1655278820 1655278820 Mrt_ 30.txt
46: 0 0 0 0 45 48 1655278820 1655278820 Mrt_ 31.txt
47: 0 0 0 0 46 48 1655278820 1655278820 Mrt_ 32.txt
48: 0 0 0 0 47 48 1655278820 1655278820 Mrt_ 33.txt
49: 0 0 0 0 48 48 1655278820 1655278820 Mrt_ 34.txt
50: 0 0 0 0 49 48 1655278820 1655278820 Mrt_ 35.txt
51: 0 0 0 0 50 48 1655278820 1655278820 Mrt_ 36.txt
52: 0 0 0 0 51 48 1655278820 1655278820 Mrt_ 37.txt
53: 0 0 0 0 52 48 1655278820 1655278820 Mrt_ 38.txt
54: 0 0 0 0 53 48 1655278820 1655278820 Mrt_ 39.txt
55: 0 0 0 0 54 48 1655278820 1655278820 Mrt_ 40.txt
56: 0 0 0 0 55 48 1655278820 1655278820 Mrt_ 41.txt
57: 0 0 0 0 56 48 1655278820 1655278820 Mrt_ 42.txt
58: 0 0 0 0 57 48 1655278820 1655278820 Mrt_ 43.txt
59: 0 0 0 0 58 48 1655278820 1655278820 Mrt_ 44.txt
60: 0 0 0 0 59 48 1655278820 1655278820 Mrt_ 45.txt
61: 0 0 0 0 60 48 1655278820 1655278820 Mrt_ 46.txt
62: 0 0 0 0 61 48 1655278820 1655278820 Mrt_ 47.txt
63: 0 0 0 0 62 48 1655278820 1655278820 Mrt_ 48.txt
64: 0 0 0 0 63 48 1655278820 1655278820 Mrt_ 49.txt
65: 0 0 0 0 64 48 1655278820 1655278820 Mrt_ 50.txt
66: 0 0 0 0 65 48 1655278820 1655278820 Mrt_ 51.txt
67: 0 0 0 0 66 48 1655278820 1655278820 Mrt_ 52.txt
68: 0 0 0 0 67 48 1655278820 1655278820 Mrt_ 53.txt
69: 0 0 0 0 68 48 1655278820 1655278820 Mrt_ 54.txt
70: 0 0 0 0 69 48 1655278820 1655278820 Mrt_ 55.txt
71: 0 0 0 0 70 48 1655278820 1655278820 Mrt_ 56.txt
72: 0 0 0 0 71 48 1655278820 1655278820 Mrt_ 57.txt
73: 0 0 0 0 72 48 1655278820 1655278820 Mrt_ 58.txt
74: 0 0 0 0 73 48 1655278820 1655278820 Mrt_ 59.txt
75: 0 0 0 0 74 48 1655278820 1655278820 Mrt_ 60.txt
76: 0 0 0 0 75 48 1655278820 1655278820 Mrt_ 61.txt
< Skiped 77 - 79 >
80: 0 0 0 0 76 48 1655278820 1655278820 Mrt_ 62.txt
81: 0 0 0 0 80 48 1655278820 1655278820 Mrt_ 63.txt
82: 0 0 0 0 81 48 1655278820 1655278820 Mrt_ 64.txt
83: 0 0 0 0 82 48 1655278820 1655278820 Mrt_ 65.txt
...
517: 0 0 0 0 516 48 1655278822 1655278822 Mrt_481.txt
518: 0 0 0 0 517 48 1655278822 1655278822 Mrt_482.txt
519: 0 0 0 0 518 48 1655278822 1655278822 Mrt_483.txt
520: 0 0 0 0 519 48 1655278822 1655278822 Mrt_484.txt
521: 0 0 0 0 520 48 1655278822 1655278822 Mrt_485.txt
522: 0 0 0 0 521 48 1655278822 1655278822 Mrt_486.txt
523: 0 0 0 0 522 48 1655278822 1655278822 Mrt_487.txt
524: 0 0 0 0 523 48 1655278822 1655278822 Mrt_488.txt
< Skiped 525 - 527 >
528: 0 0 0 0 524 48 1655278822 1655278822 Mrt_489.txt
529: 0 0 0 0 528 48 1655278822 1655278822 Mrt_490.txt
530: 0 0 0 0 529 0 1655449988 0 mtpindex.dat
So the file was only about 18K...


Now back to playing
 
Very cool Kurt, will see about updating makefiles to allow it - and the debug.

Maybe add a #define in MTP_storage.h to ID when that version of the lib is present ... so it can do the right thing when present or not for now? Will have to see what it looks like ... some hours away ...
 
Quick update:

I pushed up some additional changes to the branch I mentioned above.

With this, I fixed some of the debug output.

I also added the code, that if it fails to open the index file on the storage specified, it will then try to fall back to using the new memory storage.

I also hacked up my sd_debug sketch to add 2nd SD device on pin 10, and then tried running it with no SD in the SDIO slot and one in the SPI SD slot.
With current released code you will not be able to enumerate the SPI SD card... but no code allowed it.

Code:
No SD Card
Added SD2 card using built in SDIO, or given SPI CS

Setup done
Failed to open Index file on storage number 0 try memory File
!!!IndexMemFS::open

Dump Storage list(2)
store:0 storage:10001 name:SD1 fs:20000f64
store:1 storage:20001 name:SD2 fs:20000fb4

Dump Index List
0: 0 1 0 65535 0 0 0 0 /
1: 1 1 1 65535 0 52 0 0 /
16: 1 1 1 1 0 66 1636540446 1636540446 System Volume Information
17: 1 0 0 1 16 162667688 1629616200 1629616200 Logic+Setup+2.3.39-master.xxx
18: 1 0 0 1 17 26917168 1546300816 1546300818 sixaxispairtoolsetup-0.3.1.xxx
19: 1 0 0 1 18 3135327 1638350040 1638339894 SDTEST4.mp3
...
Need to test more and #if stuff around it, so that this code probably won't be there for lower memory boards like T3.2
Once that is checked will probably merge it back into main.
 
@KurtE
> did @koromix publish an updated TyComm for PID_VID::MTP+Serial? I missed it is so ... if not can you point to one?

- got the updated code.
Inserted SD card running the sd_mtp_debug not sure what this is saying and a search for 'skipped' with Sublime not showing the source?
581: 0 0 0 0 580 992 1546301146 1546301146 992_Mrt486.txt
< Skiped 582 - 591 >
592: 0 0 0 0 581 992 1546301146 1546301146 992_Mrt487.txt
Oh wait I see one of us mspoilled skiped ...

edit and re-ran: Coming from this line ~1280 (not 1290):
Code:
			// try to detect invalid/delected items: name[0] = 0...
			if (p.name[0] == '\0') {
				if (skip_start_index == 0) skip_start_index = ii;
			} else {
				if (skip_start_index) {
					[B]MTP_class::PrintStream()->printf("< Skipped? %u - %u >\n", skip_start_index, ii-1);[/B]
					skip_start_index = 0;
				}
Is this just for sparse output, or suggesting a problem?
 
> did @koromix publish an updated TyComm for PID_VID::MTP+Serial? I missed it is so ... if not can you point to one?

I have not seen one... I will try to put a copy of it somewhere on web and send link to you... I am pretty sure the zip file would be too large to email or post.

581: 0 0 0 0 580 992 1546301146 1546301146 992_Mrt486.txt
< Skiped 582 - 591 >
592: 0 0 0 0 581 992 1546301146 1546301146 992_Mrt487.txt
Oh wait I see one of us mspoilled skiped ...

edit and re-ran: Coming from this line ~1280 (not 1290):

Is this just for sparse output, or suggesting a problem?
Fixed skipped.

And it is normal that it skips some numbers. The Object IDs are used as identifiers between the host and us... There are certain rules for this, like maybe special identifier ranges for Storage IDs..

So there is a hack in the code, that I keep the index in chunks of memory. And I try to encode several objects into each chunk. How many depends on how long their file names are. I also try to reserve some space for the cases where file names change length... And then I encode in the object id, a chunk number, and index of the object within the chunk.
And so if when enumerating it finds it can not fit the maximum number of items defined for how many can fit within block (Currently defined as 64), then you will see how many indexes were skipped.
 
Thanks Kurt.
It was late and I ran the sdmtpDebug and saw that and until I found the code it was too late to discover the logic behind it.
And my head hurt after seeing 'skiped' on one screen and re-trying to find skipped on the other screen and wondering why Sublime was letting me down :)


My repeat postings in prior day found two things:
> it seems the corruption on the SD card is from the mtpindex.dat file? Maybe from it never being closed on Teensy side?
> instance of a single file dropping 512, or larger, set of bytes in one of Many files when pulling files over MTP from Teensy to Windows

Other than that, the file copy from Teensy was good and the copy to Teensy showed no issues as tried.
 
Back
Top