> On Okt. 14, 2014, 9:13 nachm., David Faure wrote: > > kioslave/trash/trashimpl.cpp, line 170 > > <https://git.reviewboard.kde.org/r/120573/diff/6/?file=318520#file318520line170> > > > > Shouldn't this return false like the other blocks? > > > > And then I would swap the if and else blocks, removing the '!' in the > > condition... so that all if() blocks follow the same pattern. > > > > I see that the code below tries to cope with the case where we couldn't > > create KDE.trash ... but then we shouldn't set any error code, if we > > fallback to another solution. > > > > However I'm not sure I understand why this could happen though. Why > > wouldn't we be able to create "KDE.trash" but we would be able to create > > "info"? Well, this would be the case if KDE.trash existed already and was > > owned by another user, but then the same could happen with "info"... > > René J.V. Bertin wrote: > Modified as suggested. I agree that the error shouldn't occur. Normally > it *cannot* occur for the reason you indicate unless another user wrote an > entry in this user's Trash explicitly and "by hand". However I'm not sure how > KDE_mkdir handles a situation in which a (read-only) _file_ of the same name > is already present, owned by the same user. While that is unlikely it's not > entirely impossible either. > > David Faure wrote: > mkdir will fail with errno==EEXIST if a dir (or file) already exists with > the same name, anyway (no matter what the permissions and ownership are). > > I just don't like that this code can use either trashPath or > trashPath+"/KDE.trash", and has to handle both cases everywhere, including > "hacks" like "if endsWith("/KDE.trash")". > We should pick one way and stick to it, anything else increases > complexity and therefore the risk of bugs. > > "remove the subdirectory we couldn't create and use the standard KDE > infrastructure" is weird if you have decided that the "KDE infrastructure" on > OS X *is* trashdir+"/KDE.trash". > > René J.V. Bertin wrote: > Point taken. > > Now the question is, how am I going to implement a function that > (re)creates the infrastructure if it has been deleted? Is trashimpl.h part of > the external API, i.e. can I add a function to TrashImpl - and would that > have to be a function available everywhere (but a stub on all but OS X), or a > function that only exists on OS X? > > Thomas Lübking wrote: > > http://api.kde.org/frameworks-api/frameworks5-apidocs/kio/html/classTrashImpl.html > > On the $TRASH/KDE.trash issue and in general: > OS_X stores trashed files directly in ~/.Trash, I take? > In that case i foresee a general issue (maybe academic, but possible) > with the approach to store the KDE trash stuff there (which OSX will take as > trashed files). > > What happens if you delete a file named "info" or "files" or "KDE.trash"? > In either case you'd likely run into a conflict? Ie. either OS_X cannot > trash the new file (for there's a directory of that name) or OS_X > overrides/invalidates the entire KDE trash or OS_X creates such file and you > can't add the KDE stuff there. > Yesno? > > In case: how does the OS_X trash handle hidden (.*) files? > Assuming it doesn't put hidden files dotted into the trash, how does it > react when adding a hidden file there (whether .info, .files or .KDE.trash)? > > René J.V. Bertin wrote: > In fact, it works exactly the way the KDE trash works, except for the > restore info which (I presume) is stored in the file metadata. > So: > > - deleting a file that has the same name as a file already in the trash > will 1) rename that file to something like "name 1" and 2) move that file > into the trash. (I've been able to see that happen when the system is very > busy). In short, it's only if someone already put a KDE.trash in the trash > that we'd into trouble, unless it's a directory. > - Why wouldn't it put hidden files there? Again, the Finder works like > Dolphin or Nautilus: hidden files are nothing special, they're just not shown > in the Finder (nor in file selection dialogs). > > I'm not sure if the trash would show as non-empty if we store everything > under ~/.Trash/.KDE.trash but if it does we have the problem that the user > won't understand why when s/he opens the Trash in the Finder. And if it > doesn't we're more or less back where we started. > I think it's important that KDE waste becomes visible in the OS X Trash, > preferably in a subdirectory.
> Why wouldn't it put hidden files there? Counterfeit - there's only limited reason to hide a file in the trash (the kioslave simply shows them), so I could have assumed it's renamed .foo -> _.foo or so. Does OS_X consider an empty directory in ~/.Trash a non-empty trash (notably if it has no meta/restorage data)? The "ideal" solution to me seems to ensure there's always OUR (we can hardly re-use a directory the user deleted there via the OS_X tash) ~/.Trash/KDE.trash dir (so OS_X will avoid that name) and convince the OS_X trash to ignore it while empty. If we cannot make OS_X ignore it, such directory must be created avoiding any collision w/ relgularily deleted files/dirs (ie. if there's such file or dir, *we* must becom KDE.trash_1 or similar) The tricky part will be to (persistently) export the legal KDE.trash* path to all clients (config key? but it must be updated by any running process whenever the path changes) - Thomas ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/120573/#review68418 ----------------------------------------------------------- On Okt. 15, 2014, 4:26 nachm., René J.V. Bertin wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/120573/ > ----------------------------------------------------------- > > (Updated Okt. 15, 2014, 4:26 nachm.) > > > Review request for KDE Software on Mac OS X, KDE Runtime and David Faure. > > > Repository: kde-runtime > > > Description > ------- > > KDE on OS X does not handle the desktop session (no "Plasma") nor can it rely > on XDG to obtain the proper paths to use for something like the trash. As a > result, all applications that propose to move things they manage to the > wastebin (Dolphin, but also digiKam) will store those items in a place that > has no particular meaning on OS X, and that will thus tend to fill up. > > OS X stores trash in one of several locations. Files trashed from the boot > volume (and/or the volume containing $HOME, I don't actually know that) end > up in `~/.Trash`. Files deleted from other volumes end up in > `/Volumes/volName/.Trashes/uid`, where volName is the volume name (regardless > whether it's an external or a remote drive; only mounted NFS shares are > handled differently) and uid the numerical user id. Permissions on `.Trashes` > are the same as those expected by KDE. > > The kio_trash kioslave appears to support several actual trash directory > locations, just like OS X. `TrashImpl::init()` creates a standard trash in > `~/.local/share/Trash` (at least under OS X) but also > `TrashImpl::trashForMountPoint()` that is used in cases I have not yet > encountered. > > On OS X, my modified `TrashImpl::init()` sets the standard trash directory to > `~/.Trash/KDE.trash` and will create the `files` and `info` subdirectories as > required, because they will of course be deleted when the user empties the OS > X trash. `TrashImpl::fileRemoved()` has been modified to call a new function, > `deleteEmptyTrashInfraStructure` to delete the KDE trash's internal > infrastructure when the wastebin is empty so that OS X also sees the trash as > emptied. (Since implementing `deleteEmptyTrashInfraStructure` this feature > actually works, as expected as far as I can tell). > > Remains to be done: > - determine in what cases `trashForMountPoint()` is used, and finish the > modifications for it to use `/.Trashes/uid/KDE.trash` > > > Diffs > ----- > > kioslave/trash/kcmtrash.cpp f4811fd > kioslave/trash/trashimpl.h bc68723 > kioslave/trash/trashimpl.cpp 30ee05b > > Diff: https://git.reviewboard.kde.org/r/120573/diff/ > > > Testing > ------- > > On OS X 10.6.8 with kdelibs and kde-runtime git/4.14, using Dolphin. Tested > actions are > - move items to wastebin from $HOME and a directory on a different volume > - restore items to both places > - empty wastebin through Dolphin > - empty OS X trashcan > > > Thanks, > > René J.V. Bertin > >
