Wenn irgendwo "Reserved" dran steht, dann sollte man diese Felder
imho nicht für eigene Zwecke missbrauchen. Falls das überhaupt möglich ist.
Frage: was soll dein Programm denn machen, wenn der User eine Datei außerhalb deines Programms verschoben hat und der Datenbankeintrag daher ungültig geworden ist?
Soll dann die ganze Festplatte nach einer Datei durchsucht werden, die der in der
DB entspricht? Und wenn der Anwender an der Ordnerstruktur was ändert, dann wird diese Suche für hunderte oder gar zig-tausende Dateien durchgeführt?
Ich denke, dass das dem Anwender klar sein sollte: Wenn man ein Dateiverwaltungstool nutzt, und die Dateien außerhalb des Tools verschiebt oder umbenennt, dann muss man im Anschluss die Dateien neu von dem Tool suchen lassen. Da einen Automatismus zu erwarten, halte ich für eine stark überzogene Anwender-Anforderung.
Wenn dein Tool zusätzliche Informationen zu den Dateien speichert (die ggf. auch vom Anwender bearbeitet werden können), dann gehören diese Infos
imho in die Metadaten der Datei. Zumindest solange die Dateien dadurch nicht zu sehr aufgebläht werden. Für eine eindeutige ID sollte da aber auf jeden Fall Platz sein. Oder halt alternative Wege, die (wahrscheinlich) bei den üblichen Verzeichnis-Aktionen erhalten bleiben. Alternative Datenströme an den Dateien, oder je eine versteckte "Info-Datei" pro Verzeichnis. Eine 100%ige Garantie dafür, dass die Infos erhalten bleiben, gibt es aber natürlich nicht.
Bei mp3 sind die ID3-Tags z.B. oft voll mit "Private Frames" vom Windows Media Player, iTunes und anderen, die dann von der jeweiligen "Datenbank" dahinter benutzt werden. Amazon nutzt z.B. das Kommantar-Feld für eine eindeutige Song-ID, und in einem speziellen Private-Frame werden afaik u.a. verschlüsselt Informationen zum Käufer gespeichert. Filesharing von Amazon-Mp3s ist daher eine ganz blöde Idee.
Die Tag-Formate in anderen Audio-Dateitypen können ebenso dazu genutzt werden.