They use MD5 hashes to generate unique ID for each tiddler. This was 7 years ago, maybe a mix of sha-2 + an UNIX key to ensure uniques IDS could work ?
Alternatively, the burden of ensuring an unique ID could be given to the user, who would be free to use whatever organizational system they want Thus a good future feature I think would be to allow to specify a file name instead of using the tiddler name (through a field reserved for that purpose).
This would help prevent duplicates and would also allow to specify a file extension, which would be very usefull for creating a RSS feed for example.
My apologies! I misread this and pressed every wrong button in moving this topic around because of the reference to RSS
I very much agree with this. Actual file systems also rely on the user to keep filenames unique – just enforcing it so duplicates can’t be created.
Also, what is a valid filename will differ depending on what saver / backend you are using. The rules for what can be in a Github repo vs MacOS on disk vs. what can appear in a URI are all different.
I don’t think generating unique IDs is helpful. I do think a “filename” field as an option might be helpful. This gets done automatically per saver where canonical URI is filled in.
Also: is “slug” something that is relevant for this? Might be overlap for statically generated sites, where “My Tiddler” is the tiddler name, and I want the HTTP “slug” to be “mytiddler” or “somecustomslug”. The same can apply to “My RSS Feed” and “feed.xml” being the desired path / slug.
Relying on users to keep titles unique is fine when there is user intervention, for example when creating new tiddlers. However, this is not the case with file uploads which happen primarily without user intervention.
Whether it is handled by the FileUploads plugin or the individual uploaders, the issue still needs attention. For instance on Fission, if you have an image tiddler with a title that starts with $:/ you are going to get a nasty error as that is rejected as a valid filename by Fission WNFS. Imagine that we take the easy way out and just strip the invalid characters at the beginning of the tiddler title, then $:/image.png and image.png tiddlers will both upload to the same file, that is uploading one will overwrite the other without the user even knowing this is happening.
Applying some kind of filter to tiddler titles to transform them to valid filenames is one option but the same problem persists, filter operators such as slug[] can return the same output for different inputs.
This would not work for the primary user experience that the plugin offers, namely that matching tiddlers are uploaded as soon as they exist without the need for user intervention. Moving towards some kind of workflow with mandatory user intervention would be problematic in terms of getting it to work across the different types of uploaders, not to mention a poorer user experience.
Yes, that was my point – you have to run filters over them to make them conformant on a per saver /file system basis, but turning “My Awesome Tiddler Name” into “1234-fghj-tyui” or whatever is less useful
And yes, operating systems / file systems often make choices like “Same File Name 2.txt” or similar when dupes happen. This might be pushed to the underlying system, but we’re getting into very specific things – e.g. and error that bubbles back up that says “this was a duplicate but you didn’t set an overwrite flag so we’re returning image 2.png as the file handle”
Thus a good future feature I think would be to allow to specify a file name instead of using the tiddler name (through a field reserved for that purpose).