bruns added a comment.
In D28745#674863 <https://phabricator.kde.org/D28745#674863>, @meven wrote: > In D28745#674827 <https://phabricator.kde.org/D28745#674827>, @bruns wrote: > > > In D28745#674711 <https://phabricator.kde.org/D28745#674711>, @meven wrote: > > > > > > > > > > > > > > > > Solid does not provide straight `folder => StorageVolume` yet, but I think Solid could have such a utility feature added. > > > Something like `Solid::Device::findByPath()`, it would need to canonically and recursively resolves the path parent to pay attention to symlinks. > > > This would also help D26407 <https://phabricator.kde.org/D26407> > > > > No recursion needed, `stat` provides the device. > > > Only when the file is not a symlink, if so we need to check the symlink target recursively, that's what I meant. Haven't checked the code here en detail, but the whole thumbnailing code has to work on the resolved symlinks anyway - for the data, for the thumbnail filename [1], and for the save policy. [1] https://specifications.freedesktop.org/thumbnail-spec/thumbnail-spec-latest.html#THUMBSAVE > 1. You need the **absolute canonical URI** for the original file, as stated in URI RFC 2396. In particular this defines to use three '/' for local 'file:' resources (see example below). > 2. Calculate the MD5 hash for this URI. Not for the file it points to! This results in a 128bit hash, which is representable by a hexadecimal number in a 32 character long string. >> And can you please use arc to upload the patch - it is nearly impossible to do a review with the missing context > > Or pushing it to https://community.kde.org/Infrastructure/GitLab That would even be better, yes. REPOSITORY R320 KIO Extras REVISION DETAIL https://phabricator.kde.org/D28745 To: marcingu, ivan, broulik, #dolphin, ngraham, meven, bruns Cc: thiago, bruns, meven, ngraham, kde-frameworks-devel, kfm-devel, waitquietly, azyx, nikolaik, pberestov, iasensio, aprcela, fprice, LeGast00n, cblack, fbampaloukas, alexde, Codezela, feverfew, michaelh, spoorun, navarromorales, firef, andrebarros, emmanuelp, rdieter, mikesomov
