Task/Process hängt sich scheinbar auf.

I think it is possible, yes.

The obvious issue could be a buffer over-run of some sort. I am not familiar with how Android handles the file structures.

F16 only supports DOS 8.3 format but the issue with long file names is that they take up the full 11 characters of name, and in text form actually take up 12 characters (well 13 including the separator character). Add to this the fact that you have to specify the table depth (by default 4) which F16 uses to allocate space for the path name at n*11 characters. but note that this is the path name and excludes the lowest level file name.

If your file structures exceed the the maximum permitted levels and (which 'Android' probably does) and uses long file names it is easy to see that there is scope for overflow on the directory name. I don't know if the F16 code defends against that, but I suspect not.

The extensions that I wrote for you to support long file names I deliberately avoided interfering with the underlying F16 structure, and did not use them to create directory names, basically because I did not have the source for it (I had the source for an old version so I could work out what I needed to do) so basically any issues with the F16 code will still be there even if you are using my extensions.

The fact that removing the Android and LOST.DIR folders removes the issue suggest that this may indeed be the problem. Of course, with append what is already in the file will be left there so the fact that is continues to write after the garbage is no surprise.

=======================================================================================

ch denke, es ist möglich, ja.

Das offensichtliche Problem könnte ein Pufferüberlauf irgendeiner Art sein. Ich bin nicht damit vertraut, wie Android die Dateistrukturen handhabt.

F16 unterstützt nur das DOS 8.3 Format, aber das Problem mit langen Dateinamen ist, dass sie die vollen 11 Zeichen des Namens in Anspruch nehmen und in Textform sogar 12 Zeichen (also 13 einschließlich des Trennzeichens). Hinzu kommt die Tatsache, daß Sie die Tabellentiefe angeben müssen (standardmäßig 4), die F16 verwendet, um Platz für den Pfadnamen mit n*11 Zeichen zu reservieren, aber beachten Sie, daß dies der Pfadname ist und den Dateinamen der untersten Ebene ausschließt.

Wenn Ihre Dateistrukturen die maximal zulässigen Ebenen überschreiten (was bei "Android" wahrscheinlich der Fall ist) und lange Dateinamen verwenden, ist es leicht zu erkennen, dass der Verzeichnisname überlaufen kann. Ich weiß nicht, ob der F16-Code dagegen schützt, aber ich vermute nicht.

Die Erweiterungen, die ich für Sie geschrieben habe, um lange Dateinamen zu unterstützen, habe ich absichtlich vermieden, um die zugrundeliegende F16-Struktur zu stören, und habe sie nicht verwendet, um Verzeichnisnamen zu erstellen, weil ich die Quelle dafür nicht hatte (ich hatte die Quelle für eine alte Version, so dass ich herausfinden konnte, was ich tun musste), so dass im Grunde alle Probleme mit dem F16-Code immer noch vorhanden sind, auch wenn Sie meine Erweiterungen verwenden.

Die Tatsache, dass das Entfernen der Android- und LOST.DIR-Ordner das Problem beseitigt, deutet darauf hin, dass dies tatsächlich das Problem sein könnte. Natürlich, mit append, was bereits in der Datei wird dort gelassen werden, so dass die Tatsache, dass weiterhin zu schreiben, nachdem der Müll ist keine Überraschung.




Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Regards

Merlin

Nothing guaranteed.

The obvious answer is to fix the driver somehow, but that would not be easy.

The next idea would be to increase the depth of the driver from 4 to the maximum it can go to. I have a feeling that is 16, but try the max possible.

The largest string is 255 chars so try 255/11 = 23. If it takes that it is the best you can do.

Do you get a directory listing? If so, that would be the cause of your problem, and is avoidable, I think. If you abort the directory search at the appropriate point you could avoid the problem.

I don't think that deleting the offending files is possible, at least not using F16 because you are in a catch 22 situation. The files need to be deleted one at a time starting with the deepest ones, and to do that you would build the directory string to point where it overflows.

If this is indeed the issue I think just increasing the tree depth will fix it, at least in this case.

Merlin

=============================================================================

Nichts ist garantiert.

Die naheliegende Antwort ist, den Treiber irgendwie zu reparieren, aber das wäre nicht einfach.

Die nächste Idee wäre, die Tiefe des Treibers von 4 auf das Maximum zu erhöhen, das er erreichen kann. Ich habe das Gefühl, dass das 16 ist, aber versuchen Sie das maximal Mögliche.

Die größte Zeichenkette ist 255 Zeichen, also versuchen Sie 255/11 = 23. Wenn er das aushält, ist das das Beste, was Sie tun können.

Bekommen Sie einen Verzeichniseintrag? Wenn ja, wäre das die Ursache für Ihr Problem und lässt sich meiner Meinung nach vermeiden. Wenn Sie die Verzeichnissuche an der entsprechenden Stelle abbrechen, könnten Sie das Problem vermeiden.

Ich glaube nicht, dass es möglich ist, die betreffenden Dateien zu löschen, zumindest nicht mit F16, denn Sie befinden sich in einer Catch-22-Situation. Die Dateien müssen eine nach der anderen gelöscht werden, beginnend mit den tiefsten Dateien, und um das zu tun, würden Sie die Verzeichniszeichenkette bis zu dem Punkt aufbauen, an dem sie überläuft.

Wenn dies tatsächlich das Problem ist, denke ich, dass eine Erhöhung der Baumtiefe das Problem lösen wird, zumindest in diesem Fall.

Merlin

Übersetzt mit www.DeepL.com/Translator (kostenlose Version)

Does 8 fix the problem in this case?

That gives a path length of 88 characters, which would probably be enough here.

\Android\com_go~1.y~1\files\offlinet\gUGab~1\streams

which is too big for 4 but well within 8 depth.

It is not a good solution but would at least prove that this is the issue.

=========================================================

Behebt 8 das Problem in diesem Fall?

Das ergibt eine Pfadlänge von 88 Zeichen, was hier wahrscheinlich ausreichen würde.

\Android\com_go~1.y~1\files\offlinet\gUGab~1\streams

was für 4 zu groß ist, aber gut in die Tiefe von 8 passt.

Das ist keine gute Lösung, aber es würde zumindest beweisen, dass dies das Problem ist.

Hi Miparo.



I disagree. There is a variable string that stores the path name so far. The length of that string is determined by the DirLevel Depth (specifically it is 11 * DirLevel).

==============================================================================================

Hallo Miparo.



Da bin ich anderer Meinung. Es gibt eine variable Zeichenkette, die den bisherigen Pfadnamen speichert. Die Länge dieses Strings wird durch die DirLevel Depth bestimmt (konkret ist es 11 * DirLevel).


Regards

Merlin