Curiousity? regarding file uploads.

Shard

It's been a bit, but I've come back to my fileownership plugin now that the PR it was depending on has been committed.

Okay, a long time after.

This is a two step process. The first triggers off of the filter:uploadStored. This is done because part of what I want to collect and store are the mime type of the file and its size. There are also three permutations of the filename that we want to hold on to. This information is only available as part the file upload that happens when you attach the file.

The second step fires on the action:post.save - this exists for one main reason. If you delete a file from your message, nothing ( obvious anyway ) clean up after that. So this post process checks the message body at save time, compares it to the saved data from step 1 and cleans up any deleted files.

On to the curiousities. When you look at the body content on save, you''ll see

![0_1530309721623_FileNaMe.png](/assets/uploads/files/1530309721776-filename-resized.png)

The 0 is the user id #, followed by a timestamp, then the filename. The filename and extension portion match the original file as uploaded. This is followed by the relative url to the version of the image that is posted inline in the forum. Notice that the timestamps do not match and the file has been downcased.

When you click on the image when displayed, you'll load up /assets/uploads/files/1530309721776-filename.png

So why this post? Those timestamps not matching is a little irksome. Is this on purpose? If so, why, exactly?

<baris>

I think the timestamp on the right is generated client side and the one in the url is generated server side when the file is saved so that's why they are different.

As for file ownership we have this in core now so you might not even need the plugin now. The uploads of a user are stored in a sorted set and can be viewed at /user/<slug>/uploads

Shard

@baris said in Curiousity? regarding file uploads.:

/user/<slug>/uploads

A cursory examination says no - but I need to dig a little more to be sure and then I think I need to stare at the results for a bit to see if it is better to plugin or PR for the extra bits I use that do not appear to be present here.

Also this looks like it has some of the deficiencies my initial draft had so I probably will end up doing both.

I need to churn on this for a bit.

Shard

@baris

So I have looked at this in greater detail and here are the problems 1 I see.

The sortedset really only records two bits of information: the UID and the filename. If anything more is needed the filesystem will have to be queried and logic added to evaluate the file. My view is I'd rather store this in the DB and pick it up in a single query than collect the data from the filesystem on the pageload.
This process lacks the post validation check for uploads. This leaves debris in both the database and on the file system.
I didn't spot a cleanup system that might take care of this.

1 These are from the perspective of the problem I think I am trying to solve, aside from the couple I saw that are duplicates of issues I created in my own efforts.