D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

dfaure closed this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D28901 To: dfaure, meven, ngraham Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

meven accepted this revision. meven added inline comments. This revision is now accepted and ready to land. INLINE COMMENTS > dfaure wrote in global.h:323 > There are bugs in the current kio_file implementation if StatBasic isn't set. > > mode_t type = 0; > if (details & KIO::StatBasic) { >

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

dfaure updated this revision to Diff 80428. dfaure added a comment. Remove comment change above StatBasic REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D28901?vs=80335&id=80428 BRANCH 2020_optimize_recursive_size REVISION DETAIL https://phabricator.kde.or

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

dfaure added inline comments. INLINE COMMENTS > meven wrote in trashimpl.cpp:1105 > Maybe, check for `details & KIO::StatTime` > Down the rabbit hole... Well, if StatRecursiveSize is set, we have the info, so we might as well provide it. If it's not set, then this would mean we need to do the

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

dfaure added inline comments. INLINE COMMENTS > meven wrote in global.h:323 > I don't think we should assume that, it defeats quite the purpose. > For instance even if we the ioslave gets the filename or type for its needs > it may just not include it in the UDSEntry if StatBasic was not passed.

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

meven requested changes to this revision. meven added inline comments. This revision now requires changes to proceed. INLINE COMMENTS > global.h:323 > StatNoDetails = 0x0, > -/// Filename, access, type, size, linkdest > +/// Filename, access, type, size, linkdest -- necessary for all

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

meven accepted this revision. meven added a comment. This revision is now accepted and ready to land. So we are gonna need a patch to baloo-widget stat, with `KIO::StatRecursiveSize` A test would nice for trash:/ with `KIO::StatRecursiveSize` INLINE COMMENTS > trashimpl.cpp:1105 > - > -

D28901: Add KIO::StatRecursiveSize detail value so kio_trash only does this on demand

dfaure created this revision. dfaure added reviewers: meven, ngraham. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. dfaure requested review of this revision. REVISION SUMMARY This indirectly fixes the testtrash unittest which noticed that the directory si

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure added a comment. Yep, that's it. Renaming trash:/A to trash:/B calls KIO::moveAs which stats trash:/ [useful to resolve desktop:/ to a local dir for instance], which now updates the on-disk cache... with 'A', before it gets renamed to 'B'. I think I know what the best solution is.

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure added inline comments. INLINE COMMENTS > trashimpl.cpp:1092 > +TrashSizeCache trashSize(trashPath); > +TrashSizeCache::SizeAndModTime res = > trashSize.calculateSizeAndLatestModDate(); > +size += res.size; It's actually this call which triggers the unittest failur

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure added a comment. TestTrash::renameDirInTrash makes the dir cache invalid (it still lists trashDirFromHome). I think because of the optimization that we don't always care about the size... but this had the side effect of keeping the cache uptodate I wonder if the test is too strict

D24773: kio_trash: Add size, modification, access and create date for trash:/

ahmadsamir added a comment. Hello. This broke the testtrash unit test https://build.kde.org/job/Frameworks/job/kio/job/kf5-qt5%20SUSEQt5.14/45/execution/node/36/log/ REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio,

D24773: kio_trash: Add size, modification, access and create date for trash:/

This revision was automatically updated to reflect the committed changes. Closed by commit R241:570b48e656c7: kio_trash: Add size, modification, access and create date for trash:/ (authored by meven). CHANGED PRIOR TO COMMIT https://phabricator.kde.org/D24773?vs=80016&id=80061#toc REPOSI

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO BRANCH arcpatch-D24773_1 REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, n

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven marked an inline comment as done. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 80016. meven marked 2 inline comments as done. meven added a comment. Fix, typo, pass max_mtime by ref to lambda REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24773?vs=80008&id=80016 BRANCH arcpatch-D24773_1 REVISION DET

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added inline comments. INLINE COMMENTS > dfaure wrote in trashsizecache.cpp:131 > Interesting. One benefit of lambdas is that they can work on local variable; > I would have captured max_mtime by reference and modified it inside the > lambda. > Written this way (which I guess more "pure f

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added a dependent revision: D28794: Allow to display to use UDS_RECURSIVE_SIZE in status bar UDS_RECURSIVE_SIZE. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, cblack,

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure requested changes to this revision. dfaure added inline comments. This revision now requires changes to proceed. INLINE COMMENTS > trashsizecache.cpp:131 > +qint64 max_mtime = 0; > +const auto checMaxTime = [max_mtime] (const qint64 lastModTime) -> > qint64 { > +return las

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added a comment. > But I'm wondering how much effort we want to put into finding the latest mtime, this is starting to sound like a very expensive operation. I agree let's not got too deep down the rabbit hole. This is not a very common use case > When kio_

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 80008. meven marked 3 inline comments as done. meven added a comment. Add lambdas to factorize code, comments update, move a couple of DiscSpaceUtil::sizeOfPath to where there are needed REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator

D24773: kio_trash: Add size, modification, access and create date for trash:/

tory. But I'm wondering how much effort we want to put into finding the latest mtime, this is starting to sound like a very expensive operation. So I'm actually find with this known bug, maybe with a comment about how this is a heuristic -- in a fallback for bad implementations. Whe

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 79943. meven added a comment. Improve naming of struct CacheData to SizeAndModTime REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24773?vs=79942&id=79943 BRANCH arcpatch-D24773_1 REVISION DETAIL https://phabricator.kde.

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 79942. meven added a comment. This revision is now accepted and ready to land. Improve latest modification time of trash implementation, fix case when a symlink is in the trash returning incorrect trash size REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven planned changes to this revision. meven added a comment. The modification date is not what to expect currently, working on it. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, L

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure accepted this revision. This revision is now accepted and ready to land. REPOSITORY R241 KIO BRANCH arcpatch-D24773_1 REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, cblack, michaelh, n

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 79813. meven marked 4 inline comments as done. meven added a comment. Fix typo, avoid allocations, improve variable naming REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24773?vs=79804&id=79813 BRANCH arcpatch-D24773_1 RE

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure added inline comments. INLINE COMMENTS > kfileitem.h:349 > + * > + * Initialy only implemented for trash:/ > + * typo: Initially > trashimpl.cpp:1099 > + > +info = QFileInfo(trashPath); > +modified = info.lastModified(); Reusing info is more expensive (and le

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added a dependent revision: D28738: Use KFileItem::recursiveSize to Display recursize size as total size. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2,

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 79804. meven marked 3 inline comments as done. meven added a comment. Rebase, update @since, add precision to KFileItem comment REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24773?vs=68829&id=79804 BRANCH arcpatch-D24773_

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven edited the summary of this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, cblack, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure added a comment. This looks good. I think I failed to notice the last update, sorry for the delay. Can you rebase (I suspect a few conflicts) and update version numbers to 5.70? Then it'll be good to go. Ah, and the documentation for the KFileItem getter needs to say that thi

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 68829. meven added a comment. Add KIO::UDSEntry::UDS_RECURSIVE_SIZE to store recursive size of folders REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24773?vs=68402&id=68829 BRANCH arcpatch-D24773 REVISION DETAIL https:

D24773: kio_trash: Add size, modification, access and create date for trash:/

for nothing -- even here it's not fully for free. Some ioslave could provide it by default in some situation like for kio_trash, this make sense for /. > One solution would be to use the "details" metadata for this. > > - 0 (as set by DeleteJob) means bar

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure added a comment. You can do whatever you want in the GUI -- I'll happily step out of that part of the discussion --, as long as you don't abuse UDS_SIZE for what it was not meant for, thus creating an ambiguous meaning for it. My suggestion would be to add a UDS_RECURSIVE_SIZE ins

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added a comment. In D24773#551497 , @ngraham wrote: > In D24773#551245 , @meven wrote: > > > I would argue that "Disk space usage" and "Size" might be confusing to users. A folder size is the s

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added a comment. In D24773#551497 , @ngraham wrote: > In D24773#551245 , @meven wrote: > > > I would argue that "Disk space usage" and "Size" might be confusing to users. A folder size is the s

D24773: kio_trash: Add size, modification, access and create date for trash:/

ngraham added a comment. In D24773#551245 , @meven wrote: > I would argue that "Disk space usage" and "Size" might be confusing to users. A folder size is the size of his content idiomatically. > That is our current usage of Size field for fol

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven marked 2 inline comments as done. meven added a comment. In D24773#551087 , @dfaure wrote: > I meant in the Dolphin view. RMB / Properties and calculating the size is available for trash:/. See http://www.davidfaure.fr/2019/dolphin_propert

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure requested changes to this revision. dfaure added a comment. This revision now requires changes to proceed. I meant in the Dolphin view. RMB / Properties and calculating the size is available for trash:/. See http://www.davidfaure.fr/2019/dolphin_properties_dialog_for_trash.png I d

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven marked 3 inline comments as done. meven added inline comments. INLINE COMMENTS > dfaure wrote in trashimpl.cpp:1088 > This method could be const, right? No becauseof the call to `list()` that cannot be const. > dfaure wrote in trashimpl.cpp:1104 > This looks very slow. We have a cache for

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven updated this revision to Diff 68402. meven added a comment. Use TrashSizeCache to file directory size, do not add creation date to the UDSEntry, better use UDSEntry reserve/clear REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D24773?vs=68281&id=68402 BRA

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven edited the summary of this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

ngraham added a comment. Works great. Not sure creation date makes sense to show for the trash (if it's available) though. Can we suppress that? REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-framew

D24773: kio_trash: Add size, modification, access and create date for trash:/

dfaure requested changes to this revision. dfaure added inline comments. This revision now requires changes to proceed. INLINE COMMENTS > kio_trash.cpp:500 > KIO::UDSEntry entry; > +entry.clear(); > createTopLevelDirEntry(entry); why? > trashimpl.cpp:1088 > > +KIO::UDSEntry Tras

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven removed a dependent revision: D24774: Allow non-local directories to provide UDS_SIZE. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven marked 3 inline comments as done. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven marked 2 inline comments as done. meven added inline comments. INLINE COMMENTS > elvisangelaccio wrote in trashimpl.cpp:1091 > Is this really needed? We just created `entry`. It was done previously in void TrashProtocol::createTopLevelDirEntry to save some memory, so I just kept it here a

D24773: kio_trash: Add size, modification, access and create date for trash:/

elvisangelaccio added a reviewer: dfaure. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio, dfaure Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

elvisangelaccio added a comment. +1 INLINE COMMENTS > trashimpl.cpp:1091 > +KIO::UDSEntry entry; > +entry.clear(); > + Is this really needed? We just created `entry`. > trashimpl.cpp:1094 > +// refresh list of trashes and get the list of files in them > +const TrashedFileInf

D24773: kio_trash: Add size, modification, access and create date for trash:/

ngraham added a dependent revision: D24774: Allow non-local directories to provide UDS_SIZE. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven added a reviewer: elvisangelaccio. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D24773 To: meven, #frameworks, ngraham, elvisangelaccio Cc: kde-frameworks-devel, LeGast00n, GB_2, michaelh, ngraham, bruns

D24773: kio_trash: Add size, modification, access and create date for trash:/

meven created this revision. meven added reviewers: Frameworks, ngraham. Herald added a project: Frameworks. Herald added a subscriber: kde-frameworks-devel. meven requested review of this revision. REVISION SUMMARY BUG: 413091 REPOSITORY R241 KIO BRANCH master REVISION DETAIL https://p

D13918: Use non deprecated fastInsert in kio_trash

This revision was automatically updated to reflect the committed changes. Closed by commit R241:7b1210091c55: Use non deprecated fastInsert in kio_trash (authored by jtamate). REPOSITORY R241 KIO CHANGES SINCE LAST UPDATE https://phabricator.kde.org/D13918?vs=37232&id=37265 REVISION DE

D13918: Use non deprecated fastInsert in kio_trash

jtamate edited the summary of this revision. REPOSITORY R241 KIO REVISION DETAIL https://phabricator.kde.org/D13918 To: jtamate, dfaure, #frameworks Cc: kde-frameworks-devel, michaelh, ngraham, bruns

D13918: Use non deprecated fastInsert in kio_trash

dfaure accepted this revision. dfaure added a comment. This revision is now accepted and ready to land. I remember there were good reasons for not setting UDS_LOCAL_PATH in kio_trash, but by now I forgot what they were exactly :-) I expect that some code will resolve to local paths

D13918: Use non deprecated fastInsert in kio_trash

jtamate created this revision. jtamate added reviewers: dfaure, Frameworks. Restricted Application added a project: Frameworks. Restricted Application added a subscriber: kde-frameworks-devel. jtamate requested review of this revision. REVISION SUMMARY This is the last one for kio The entry is

Re: Review Request 128910: [kio_trash] Fill in UDS_LOCAL_PATH in UDSEntry

tance, deleting the file will do a direct deletion using the local path, not using kio_trash, and therefore leaving the .trashinfo file lying around (and not updating the total size usage of the trash). And more such unwanted side effects. Do we really need previews of folders in the trash? How abo

Re: Review Request 128910: [kio_trash] Fill in UDS_LOCAL_PATH in UDSEntry

uming the files/folders are remote and > copying them to /tmp when generating previews. > This is especially annoying and dangerous if there are large folders in the > trash. > > KDE4's kio_trash in kde-runtime has the same problem, as the code is > basically the sam

Review Request 128910: [kio_trash] Fill in UDS_LOCAL_PATH in UDSEntry

assuming the files/folders are remote and copying them to /tmp when generating previews. This is especially annoying and dangerous if there are large folders in the trash. KDE4's kio_trash in kde-runtime has the same problem, as the code is basically the same, the same patch fixes i

Re: Review Request 125290: Refresh Solid's device list before querying in kio_trash

Qt event loop before querying Solid's device list. Solid caches devices and relies on signals to refresh them (at the very least that's how fstab backend works) which is a problem if kio_trash process is reused. Currently if kio_trash process is reused and there were some device cha

Re: Review Request 125290: Refresh Solid's device list before querying in kio_trash

- > > We need to process events in Qt event loop before querying Solid's device > list. Solid caches devices and relies on signals to refresh them (at the very > least that's how fstab backend works) which is a problem if kio_trash process > is reused. > > Currentl

Re: Review Request 125290: Refresh Solid's device list before querying in kio_trash

vices and relies on signals to refresh them (at the very > least that's how fstab backend works) which is a problem if kio_trash process > is reused. > > Currently if kio_trash process is reused and there were some device changes > (for example new NFS share was mounted) ki

Re: Review Request 125290: Refresh Solid's device list before querying in kio_trash

elies on signals to refresh them (at the very > least that's how fstab backend works) which is a problem if kio_trash process > is reused. > > Currently if kio_trash process is reused and there were some device changes > (for example new NFS share was mounted) kio_trash w

Re: Review Request 125290: Refresh Solid's device list before querying in kio_trash

h them (at the very least that's how fstab backend works) which is a problem if kio_trash process is reused. Currently if kio_trash process is reused and there were some device changes (for example new NFS share was mounted) kio_trash will fail to choose valid trash directory for "tras

Review Request 125290: Refresh Solid's device list before querying in kio_trash

Description --- We need to process events in Qt event loop before querying Solid's device list. Solid caches devices and relies on signals to refresh them (at the very least that's how fstab backend works) which is a problem if kio_trash process is reused. Currently if kio_trash

Re: Review Request 125214: Add support for network shares in kio_trash

: kio Description --- kio_trash doesn't support network shares, causing "trashed" files to be copied into user's home directory. This patch adds support for them by assigning them persistent ID's (because there is no device minor/major ID or any other integer we c

Re: Review Request 125214: Add support for network shares in kio_trash

ed Sept. 14, 2015, 10:31 a.m.) > > > Review request for KDE Frameworks and David Faure. > > > Bugs: 177023 > https://bugs.kde.org/show_bug.cgi?id=177023 > > > Repository: kio > > > Description > --- > > kio_trash doesn't suppor

Re: Review Request 125214: Add support for network shares in kio_trash

:31 p.m.) > > > Review request for KDE Frameworks and David Faure. > > > Bugs: 177023 > https://bugs.kde.org/show_bug.cgi?id=177023 > > > Repository: kio > > > Description > --- > > kio_trash doesn't support network shares, causing "

Re: Review Request 125214: Add support for network shares in kio_trash

and David Faure. Bugs: 177023 https://bugs.kde.org/show_bug.cgi?id=177023 Repository: kio Description --- kio_trash doesn't support network shares, causing "trashed" files to be copied into user's home directory. This patch adds support for them by assigning

Re: Review Request 125214: Add support for network shares in kio_trash

-- > > (Updated Sept. 13, 2015, 10:19 p.m.) > > > Review request for KDE Frameworks and David Faure. > > > Bugs: 177023 > https://bugs.kde.org/show_bug.cgi?id=177023 > > > Repository: kio > > > Description > --- > > kio_trash d

Re: Review Request 125214: Add support for network shares in kio_trash

and David Faure. Bugs: 177023 https://bugs.kde.org/show_bug.cgi?id=177023 Repository: kio Description --- kio_trash doesn't support network shares, causing "trashed" files to be copied into user's home directory. This patch adds support for them by assigning

Re: Review Request 125214: Add support for network shares in kio_trash

> On Sept. 13, 2015, 8:48 p.m., David Faure wrote: > > Thanks for the patch! > > > > Protecting write access to a file is better done with QLockFile (which I > > added to Qt 5.0) than with a DBus based mechanism. > > > > (btw I just noticed that KInte

Re: Review Request 125214: Add support for network shares in kio_trash

> On Sept. 13, 2015, 10:48 p.m., David Faure wrote: > > Thanks for the patch! > > > > Protecting write access to a file is better done with QLockFile (which I > > added to Qt 5.0) than with a DBus based mechanism. > > > > (btw I just noticed that KInte

Re: Review Request 125214: Add support for network shares in kio_trash

better done with QLockFile (which I added to Qt 5.0) than with a DBus based mechanism. (btw I just noticed that KInterProcessLock is now unused in kio_trash, we should delete it, once your patch is in) - David Faure On Sept. 13, 2015, 7:59 p.m., Bartosz Sławianowski wrote

Re: Review Request 125214: Add support for network shares in kio_trash

and David Faure. Bugs: 177023 https://bugs.kde.org/show_bug.cgi?id=177023 Repository: kio Description (updated) --- kio_trash doesn't support network shares, causing "trashed" files to be copied into user's home directory. This patch adds support for them by assig

Review Request 125214: Add support for network shares in kio_trash

https://bugs.kde.org/show_bug.cgi?id=177023 Repository: kio Description --- kio_trash doesn't support network shares, causing "trashed" files to be copied into user's home directory. This patch adds support for them by assigning them persistent ID's (because there is

Re: kio_trash

>>> have the full history of kio_trash but only partial history of kio, if >>> you didn't graft kdelibs in. >> >> In fact, half the commits in kio are now from kio_trash. I didn't push >> yet. I wonder if we should do the graft thing instead... S

Re: kio_trash

MT-03:00 Nicolás Alvarez : >> > >>> Done. The resulting history looks kind of weird though, because we >> > >>> have the full history of kio_trash but only partial history of kio, if >> > >>> you didn't graft kdelibs in. >> > >&g

Re: kio_trash

resulting history looks kind of weird though, because we > > >>> have the full history of kio_trash but only partial history of kio, if > > >>> you didn't graft kdelibs in. > > >> > > >> In fact, half the commits in kio are now from kio_tra

Re: kio_trash

On Saturday 13 September 2014 20:29:18 Luigi Toscano wrote: > Luigi Toscano ha scritto: > > Nicolás Alvarez ha scritto: > >> 2014-09-13 15:13 GMT-03:00 Nicolás Alvarez : > >>> Done. The resulting history looks kind of weird though, because we > >>> h

Re: kio_trash

Luigi Toscano ha scritto: > Nicolás Alvarez ha scritto: >> 2014-09-13 15:13 GMT-03:00 Nicolás Alvarez : >>> Done. The resulting history looks kind of weird though, because we >>> have the full history of kio_trash but only partial history of kio, if >>> you di

Re: kio_trash

Nicolás Alvarez ha scritto: > 2014-09-13 15:13 GMT-03:00 Nicolás Alvarez : >> 2014-09-09 12:22 GMT-03:00 David Faure : >>> On Sunday 17 August 2014 00:03:41 David Faure wrote: >>>> kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers >>&

Re: kio_trash

2014-09-13 15:13 GMT-03:00 Nicolás Alvarez : > 2014-09-09 12:22 GMT-03:00 David Faure : >> On Sunday 17 August 2014 00:03:41 David Faure wrote: >>> kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers >>> API that depends on kio_trash (KIO::tras

Re: kio_trash

2014-09-09 12:22 GMT-03:00 David Faure : > On Sunday 17 August 2014 00:03:41 David Faure wrote: >> kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers >> API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash, >> support for trash in

Re: kio_trash

On Sunday 17 August 2014 00:03:41 David Faure wrote: > kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers > API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash, > support for trash in FileUndoManager, and I'm about to add a > KIO:

Re: kio_trash

On Sunday 17 August 2014 00:03:41 David Faure wrote: > kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers > API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash, > support for trash in FileUndoManager, and I'm about to add a > KIO:

Re: kio_trash

On Sunday 17 August 2014 00:03:41 David Faure wrote: > kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers > API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash, > support for trash in FileUndoManager, and I'm about to add a > KIO:

kio_trash

kio_trash is currently in kde-workspace/kio-extras, but KIO actually offers API that depends on kio_trash (KIO::trash(), JobUiDelegateExtension::Trash, support for trash in FileUndoManager, and I'm about to add a KIO::restoreFromTrash job). And KIO::trash is called from the file d