3 ms·

I would recommend not moving around files that are under program control. Have a means to do so through the program. If the program must support files being mo

I would recommend not moving around files that are under program control. Have a means to do so through the program. If the program must support files being moved underneath it, use an extended attribute to mark the files with a UUID or equivalent such as NTFS's OBJECTID. If that is not possible, use a combination of the file's fileid or inode number and its mtime and size to match up the missing files with files found elsewhere.

compressedgas 4y ago
Note that this only can detect moved unmodified files, unless the program that did the modification preserved the extended attributes or OBJECTID by either modifying the file in-place or by copying the extended attributes or with OBJECTID by using ReplaceFile.
- sandreas 4y ago
  That is exactly the problem... keeping a unique "file identifier" while changing everything else (date, size, location)... hashing is a slow but pretty accurate approach for this. But maybe not the best / right one. There is also `chromaprint`[1] in ffmpeg - maybe this can be utilized, too... but I still think it is too slow. I think I have to test this out and provide the "don't lose your history" as experimental approach. Performance is king... especially when indexing or importing. Nobody wants to wait 3 days until his library is indexed :-) [1]: http://underpop.online.fr/f/ffmpeg/help/chromaprint-1.htm.gz http://underpop.online.fr/f/ffmpeg/help/chromaprint-1.htm.gz
sandreas 4y ago
> I would recommend not moving around files that are under program control. Have a means to do so through the program. Thank you. That is something I thought of, too. Maybe this requires sort of an "import procedure" with a frontend. Nice idea, but the hashing question still is important to me, just to understand, if this would be enough to avoid collisions > use an extended attribute to mark the files with a UUID or equivalent such as NTFS's OBJECTID Yeah that could work... inode number and mtime may be a problem in a docker environment - size is already part of my question (more accurate: audiodata size because the file size often changes when metadata does). I'll check that again. A custom metadata tag (like TXXX:tonehubid for id3) would also work, but I don't wanna embed this information directly into the file, because if I share files with a friend and he also uses tonehub, it could end in a conflict or data loss...

compressedgas 4y ago

Note that this only can detect moved unmodified files, unless the program that did the modification preserved the extended attributes or OBJECTID by either modifying the file in-place or by copying the extended attributes or with OBJECTID by using ReplaceFile.

sandreas 4y ago
That is exactly the problem... keeping a unique "file identifier" while changing everything else (date, size, location)... hashing is a slow but pretty accurate approach for this. But maybe not the best / right one. There is also `chromaprint`[1] in ffmpeg - maybe this can be utilized, too... but I still think it is too slow. I think I have to test this out and provide the "don't lose your history" as experimental approach. Performance is king... especially when indexing or importing. Nobody wants to wait 3 days until his library is indexed :-) [1]: http://underpop.online.fr/f/ffmpeg/help/chromaprint-1.htm.gz http://underpop.online.fr/f/ffmpeg/help/chromaprint-1.htm.gz

sandreas 4y ago

> I would recommend not moving around files that are under program control. Have a means to do so through the program. Thank you. That is something I thought of, too. Maybe this requires sort of an "import procedure" with a frontend. Nice idea, but the hashing question still is important to me, just to understand, if this would be enough to avoid collisions > use an extended attribute to mark the files with a UUID or equivalent such as NTFS's OBJECTID Yeah that could work... inode number and mtime may be a problem in a docker environment - size is already part of my question (more accurate: audiodata size because the file size often changes when metadata does). I'll check that again. A custom metadata tag (like TXXX:tonehubid for id3) would also work, but I don't wanna embed this information directly into the file, because if I share files with a friend and he also uses tonehub, it could end in a conflict or data loss...