On 10/7/23 00:35, Oliver Webb wrote: >> Is it the "touch" that fails, or tar? Because the test is doing: > > Putting a ' || echo "whatever" ' after the touch command that creates the > long filenames shows nothing, > these are the logs from the test failure: > > ln: failed to create symbolic link 'dir/[250 CHAR FILENAME (starts with 6)]' > -> '[255 CHAR FILENAME (starts with 1)]': File name too long > tar: dir/[250 CHARACTER FILENAME (starts with 6)]: File name too long > tar: had errors > FAIL: tar create long->long
Aha, that's a different test. That's doing: ln -s $LONG dir/${LONG:5} testing "create long->long" "$TAR dir/${LONG:5} | SUM 7" \ "b9e24f53e27496c5125445230d201b4a36ff7398\n" "" "" And the ln call before tar is failing, which on ext4 does: $ LONG=0123456789abcdef0123456789abcdef $ LONG=$LONG$LONG$LONG$LONG$LONG$LONG$LONG$LONG $ LONG=${LONG:1:255} $ mkdir dir $ ln -s $LONG dir/${LONG:5} $ ls -l dir total 4 lrwxrwxrwx 1 landley landley 255 Oct 8 00:58 6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345 6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345 6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef012345 6789abcdef0123456789abcdef0123456789abcdef0123456789abcdef -> 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef (I had mercy and manually wordwrapped that last bit.) And in fact: $ touch dir/$(readlink dir/*) landley@driftwood:~/toybox/toybox/subb$ ls -l dir total 4 -rw-r--r-- 1 landley landley 0 Oct 8 01:02 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef0 123456789abcdef0123456789abcdef0123456789abcdef0123456789abcdef But the thing is, it's not saying _link_ too long. A link can be a path, or an arbitrary string, it's not policed by the filesystem until you try to resolve it: $ ln -s "$(seq 1 1000 | xargs)" dir/potato $ ls dir/potato ls: cannot access 'dir/potato': File name too long $ ls -ld dir/potato | wc 1 1010 3954 It's saying the _filename_ that ln is trying to create is too long. I.E. it's not that ecryptfs can't handle a filename of length 255, it can't handle one of length 250. What is the maximum... https://unix.stackexchange.com/questions/32795/what-is-the-maximum-allowed-filename-and-folder-size-with-ecryptfs Filenames expand during encryption, and the maximum length ecryptfs supports is 143 characters. Right, lemme try to get it to skip that test if the ln fails... >> Do you mean the tests/truncate.test entry: >> >> testing "is sparse" "truncate -s 1g freep && [ $(stat -c %b freep) -le 8 ] && >> echo okay" "okay\n" "" "" >> >> Which is doing a "truncate -s 1g file" and then asking state if the file with >> literally no contents used less than 8 512-byte blocks of storage? > > That's the one Try now. >> Is it triggering ASAN in mkpasswd or in a different toybox command out of the >> $PATH? (Yay reproduction sequence, but WHAT did it reproduce?) > > Putting toybox commands into my PATH runs test_mkpasswd fine, So I don't > think it's some other toybox command. > And since the lib/password.c plumbing got rewritten and needs to be audited > that naturally seemed > like the issue. Quite likely. I wonder why it's passing for me? Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net