Hi Stef, On Thu, Apr 20, 2017 at 08:11:31PM +0200, Stephane Ducasse wrote:
Thanks for looking at this. We should really improve this part.
No problem. I've just finished coding and testing. The one part I'm not completely happy with is what I mentioned earlier: I'm not aware of any way within Pharo to determine whether two files are on the same disk filesystem, so currently the code tries a rename, and if that fails it falls back to copy and delete. If I get a chance to learn FFI soon I may try and improve it. The original FileLocatorTest>>testMoveTo test now passes, and running the entire test suite produces the same results (there are a few other tests that fail). There are some additional tests, so it currently checks: - Moving files within the disk filesystem works. - Moving files within the memory filesystem works. - Moving files from the memory filesystem to the disk filesystem works. Since this is a core part of the system, I'm going to wait until Pharo 7 development begins before posting the patch. This will also provide some ad-hoc testing as I've got this in my daily work image. Cheers, Alistair
On Wed, Apr 19, 2017 at 9:41 PM, Alistair Grant <akgrant0710@gmail.com> wrote:
Hi All,
While recently running the test suite I've been getting failures in FileLocatorTest>>testMoveTo if the working directory when the test is run is on a different unix file system to the user's home directory.
The failing primitive is 'primitiveFileRename' in module 'FilePlugin', which calls rename(), which is presumably part of libc - I didn't chase it back through the C code.
libc rename() requires the source and destination filenames to be on the same file system.
This has been discussed multiple times before:
https://pharo.fogbugz.com/f/cases/13957/Add-exception-for- cross-volume-folder-renames https://pharo.fogbugz.com/f/cases/12992/Cannot-move-files- to-another-volume-partition-under-linux https://pharo.fogbugz.com/f/cases/12965/Cannot-moveTo-FileLocator
Issue 12965 is even supposed to include a fix, although when I searched through the slice I couldn't find anything that actually looked like a fix.
As Nicolai suggested in 12965, the obvious solution is to implement move as copy+delete. It looks like there isn't an easy way to check whether the two files are on the same unix file system, so presumably it would be implemented as try to rename, and if that fails, try to copy and delete.
Is there a reason not to propose this as a patch?
Thanks, Alistair