You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This issue is used for tracking progress on the update mode implementation. This is also a place where implementation details are to be described.
The problem
FurAffinity allows users to update their published content, but doesn't make it apparent to the users which content got updated, and when. This feature allows for easy detection of changes to keep your local backup up to date, even if something got sneakily updated.
Solution
Let's examine the two semi-random URLs: https://d.facdn.net/art/voxell/1427061816/1427061575.voxell_voxell_01_small.jpg https://d.facdn.net/art/voxell/1441545741/1441545741.voxell_voxell_pixel_stretch_01.jpg
One of those has been updated in its lifetime, and the other one hasn't.
We can see that the first numeric id in the URL (let's call it Current File ID, %CURFILEID%) matches the second one (File ID) in cases when the content has not been altered. This also applies to the thumbnails, and even to the story thumbs, which is good, as it makes it possible to detect changed content without a single extra request, assuming we've saved Current File IDs the previous time.
Implementation details
When furdown detects changed content, the new version is saved under the name determined by the usual filename template, %ARTIST%\%SUBMID%.%FILEPART% by default, except in cases when this file already exists, then the template is extended by appending [%CURFILEID%].%EXT% to it.
Things get a bit messier when the local archive that needs to be checked for updates has been produced by an older version of furdown (below 0.4.9.9). On the first such update, the current IDs cache needs to be built from scratch, and this involves requesting all the relevant submissions pages. If those appear to have never been updated, IDs are just saved and no further actions are performed. Otherwise, the actual file (picture) is downloaded and compared against the local file (if one exists). If those match, the newly downloaded file gets discarded, otherwise it is kept.
Note that running an app version <0.4.9.9 after >=0.4.9.9 will delete the file IDs cache. If you need to use the two alongside each other, use at least one in the portable mode with System and temp files path setting pointing to two different places.
Progress
research
basic implementation
documenting, extensive testing
release
The text was updated successfully, but these errors were encountered:
This issue is used for tracking progress on the update mode implementation. This is also a place where implementation details are to be described.
The problem
FurAffinity allows users to update their published content, but doesn't make it apparent to the users which content got updated, and when. This feature allows for easy detection of changes to keep your local backup up to date, even if something got sneakily updated.
Solution
Let's examine the two semi-random URLs:
https://d.facdn.net/art/voxell/1427061816/1427061575.voxell_voxell_01_small.jpg
https://d.facdn.net/art/voxell/1441545741/1441545741.voxell_voxell_pixel_stretch_01.jpg
One of those has been updated in its lifetime, and the other one hasn't.
We can see that the first numeric id in the URL (let's call it Current File ID,
%CURFILEID%
) matches the second one (File ID) in cases when the content has not been altered. This also applies to the thumbnails, and even to the story thumbs, which is good, as it makes it possible to detect changed content without a single extra request, assuming we've saved Current File IDs the previous time.Implementation details
When furdown detects changed content, the new version is saved under the name determined by the usual filename template,
%ARTIST%\%SUBMID%.%FILEPART%
by default, except in cases when this file already exists, then the template is extended by appending[%CURFILEID%].%EXT%
to it.Things get a bit messier when the local archive that needs to be checked for updates has been produced by an older version of furdown (below 0.4.9.9). On the first such update, the current IDs cache needs to be built from scratch, and this involves requesting all the relevant submissions pages. If those appear to have never been updated, IDs are just saved and no further actions are performed. Otherwise, the actual file (picture) is downloaded and compared against the local file (if one exists). If those match, the newly downloaded file gets discarded, otherwise it is kept.
Note that running an app version
<0.4.9.9
after>=0.4.9.9
will delete the file IDs cache. If you need to use the two alongside each other, use at least one in the portable mode with System and temp files path setting pointing to two different places.Progress
The text was updated successfully, but these errors were encountered: