Fossil Forum

rename broken?
Login

rename broken?

(1) By David Vines (djvines) on 2020-05-29 15:05:47 [source]

I recently upgraded the level of fossil I'm using from an ancient 2.2 to 2.11. It seems that the behaviour of the rename command has changed. Is the following the expected behaviour? I certainly didn't expect the path of the file to become a merging of the old and new paths - and this isn't what 2.2 did. 

david@cubi:~$ fossil new test.fossil
project-id: eb38d270f680252aab7a98cc214b29e9b0a65945
server-id:  cc6ce265b246d4820c8fd0b5ca03830b177ab407
admin-user: david (initial password is "wWiCZvcuUX")
david@cubi:~$ fossil open test.fossil
project-name: <unnamed>
repository:   /home/david/test.fossil
local-root:   /home/david/
config-db:    /home/david/.fossil
project-code: eb38d270f680252aab7a98cc214b29e9b0a65945
checkout:     60db4d6201586e7ef36d3189926aeeca0ce24553 2020-05-29 14:59:45 UTC
tags:         trunk
comment:      initial empty check-in (user: david)
check-ins:    1
david@cubi:~$ mkdir -p a/b/1.0
david@cubi:~$ touch a/b/1.0/test.txt
david@cubi:~$ fossil add a/b/1.0/test.txt
ADDED  a/b/1.0/test.txt
david@cubi:~$ fossil commit -m "Add test file"
New_Version: eaef1631bfce6997729450b2d79a98aa9646ad9bb653c64843c3d471a82cf14b
david@cubi:~$ mv a/b/1.0 a/b/1.1
david@cubi:~$ fossil rename a/b/1.0 a/b/1.1
RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt
david@cubi:~$ fossil stat
repository:   /home/david/test.fossil
local-root:   /home/david/
config-db:    /home/david/.fossil
checkout:     eaef1631bfce6997729450b2d79a98aa9646ad9b 2020-05-29 15:01:14 UTC
parent:       60db4d6201586e7ef36d3189926aeeca0ce24553 2020-05-29 14:59:45 UTC
tags:         trunk
comment:      Add test file (user: david)
MISSING    a/b/1.1/1.0/test.txt
david@cubi:~$

(2) By Stephan Beal (stephan) on 2020-05-29 15:14:26 [link] [source] in reply to 1

RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt

Well that's unexpected. i will attempt to reproduce this in the next couple of hours and see if we can't get this resolved. If you have not already checked that in, please don't.

(3) By David Vines (djvines) on 2020-05-29 15:22:53 [link] [source] in reply to 2

Fortunately for this particular case I was able to revert and then work around the problem (renaming at the individual file level works fine, it's just the rename at the directory level that seems to be broken).

(4) By anonymous on 2020-05-29 15:47:52 [link] [source] in reply to 2

fossil rename a/b/1.0 a/b/1.1

RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt

I guess, there's some logic to this. Fossil rename got the basename (1.0) and moved into 'a/b/1.1' directory.

I wonder if the same would fail with --hard switch, as the target dir does not exist.

(5) By Stephan Beal (stephan) on 2020-05-29 15:48:01 [link] [source] in reply to 1

david@cubi:~$ mv a/b/1.0 a/b/1.1
david@cubi:~$ fossil rename a/b/1.0 a/b/1.1
RENAME a/b/1.0/test.txt a/b/1.1/1.0/test.txt

The root cause has to do with using mv before rename: if we do the same without the mv then it works. The problem is that fossil checks the filesystem for what type of file the first argument is (a/b/1.0) and if it's not there on disk, it does not know that it's a directory. After that, certain parts treat it as if it were a filename but others (a SELECT loop, it seems) treat it like multiple filename matches (i.e. as if it's a directory). Chaos ensues.

How best to resolve that, i'm not currently certain, but the workaround for the time being is to do the fossil rename first, then the mv, or to use fossil rename --hard instead, which will do the move for you.

i might have a solution, so stay tuned. Maybe someone more familiar with that particular code will propose as solution while i try this out.

(6) By Warren Young (wyoung) on 2020-05-29 16:22:05 [link] [source] in reply to 5

or to use fossil rename --hard instead

...or fossil set mv-rm-files 1, which enables --hard for fossil mv/rm always.

This option used to be something you had to enable at configure time, but it's been default-on for approximately two years now.

Indeed, I think it's time we just removed the FOSSIL_ENABLE_LEGACY_MV_RM ifdef. I can't say I recall anyone speaking of disabling the option (./configure --disable-with-legacy-mv-rm) so it's just cluttering the "make" output.

Note that I am not advocating that we change the mv-rm-files setting default.

(8) By Stephan Beal (stephan) on 2020-05-29 16:43:48 [link] [source] in reply to 6

or to use fossil rename --hard instead

...or fossil set mv-rm-files 1, which enables --hard for fossil mv/rm always.

It turns out that --hard doesn't do anything for the case that directory a/b/1.0 exists and target dir a/b/1.1 does not. Why exactly that is, i'm not sure.

(7) By Stephan Beal (stephan) on 2020-05-29 16:35:38 [link] [source] in reply to 5

The problem is that fossil checks the filesystem for what type of file the first argument is (a/b/1.0) and if it's not there on disk, it does not know that it's a directory. After that, certain parts treat it as if it were a filename but others (a SELECT loop, it seems) treat it like multiple filename matches (i.e. as if it's a directory).

Is seems that that's only half true. Fossil doesn't initialy realize that it was a local directory but appears to handle that part just fine down in the loop where it matters. However...

i might have a solution, so stay tuned.

Nope.

When a/b/1.0 is first mv'd to a/b/1.1 then this line:

https://fossil-scm.org/fossil/file?udc=1&ln=1096&ci=tip&name=src%2Fadd.c

misbehaves, producing a "zTail" value of "1.0/test.txt", which then gets appended to the destination directory name to produce "a/b/1.1/1.0/test.txt". That line is never hit if the target directory does not (yet) exist in the filesystem, and instead the bit 2 lines down from that is triggered.

What to do about that, though, is not clear to me, so i'm going to put this down for a bit and hope that someone more familiar with that code will chime in soon.

(9) By David Vines (djvines) on 2020-06-01 20:28:54 [link] [source] in reply to 7

Though like you I'm still trying to get my head around what this code is trying to achieve, I will attempt to develop a fix if I do understand it :)

(10) By anonymous on 2020-06-02 22:46:52 [link] [source] in reply to 1

MISSING a/b/1.1/1.0/test.txt

You can try the version [709d2f804].

$ fossil rename a/b/1.0 a/b/1.1
RENAME a/b/1.0/test.txt a/b/1.1/test.txt

$ fossil changes
RENAMED    a/b/1.1/test.txt

(11) By David Vines (djvines) on 2020-06-03 07:48:17 [link] [source] in reply to 10

Thank you! That fixes the problem for me.