1st partition has a different path than others.

[hjmangalam]

Hi Ganael, I was debugging some pfp code and was seeing some oddities in what was showing up on the remote end. I'm using the latest fpart executed as a system() command inside of Perl. (fpart v1.2.1 Copyright (c) 2011-2021 Ganael LAPLANCHE ganael.laplanche@martymac.org WWW: http://contribs.martymac.org Build options: debug=no, fts=system) but this goes back to at least version 1.00. The command line is a bit more complex than usual, using the -L -W flags to wait for the file write to be completed.

fpart -v -L -W 'mv $FPART_PARTFILENAME /home/hjm/pfp/fpcache' -z -s 10485760 -o \
/home/hjm/pfp/fpcache/hold/f '/home/hjm/nacs/zeba'  2> \
/home/hjm/pfp/fpcache/fpart.log.15.12.20_2021-04-07 & echo "${!}" > \
/home/hjm/pfp/fpcache/FP_PIDFILE15.12.20_2021-04-07

but that shouldn't (?) make a difference in the output. The first partition file (f.0) has the file listings relative to the target '/home/hjm/nacs' , but the rest are fully qualified. the 1st 2 lines of several of the partition files are as below. After the 1st one, they are all fully qualified.

$ head -2 f.*
==> f.0 <==
zeba/pct_hpc/dipimage
zeba/pct_hpc/diplib

==> f.1 <==
/home/hjm/nacs/zeba/pct_hpc/lib.Linuxa64/libdipio.so.original
/home/hjm/nacs/zeba/pct_hpc/lib.Linuxa64/libdml_mlv7_6.a

==> f.2 <==
/home/hjm/nacs/zeba/pct_hpc/standalone/image2pce.prj
/home/hjm/nacs/zeba/pct_hpc/standalone/image2pce.sh

==> f.3 <==
/home/hjm/nacs/zeba/pct_hpc/standalone/image2pce_mcr/lib.Linuxa64/libdml_mlv7_6.so
/home/hjm/nacs/zeba/pct_hpc/standalone/image2pce_mcr/.matlab/creation.timestamp

==> f.4 <==
/home/hjm/nacs/zeba/pct_hpc/old_lib.Linuxa64/lib.Linuxa64/libdipio.so
/home/hjm/nacs/zeba/pct_hpc/old_lib.Linuxa64/lib.Linuxa64/libdml_mlv7_6.so

This happens with other dirs as well:

$ head -2 f.*
==> f.0 <==
penner/xlab final files to run experiment/xlab install instructions.doc
penner/xlab_final_files_to_run_experiment/computer number sheet.xls

==> f.1 <==
/home/hjm/nacs/penner/dev_to_apache2.notes
/home/hjm/nacs/penner/fpart.done

==> f.2 <==
/home/hjm/nacs/penner/Django-1.0.2-final/docs/ref/models/index.txt
/home/hjm/nacs/penner/Django-1.0.2-final/docs/ref/models/instances.txt

HOWEVER, it does not happen with a more direct command, omitting the -W flag.

fpart -v -L  -z -s 2485760 -o \
> /home/hjm/pfp/fpcache/f '/home/hjm/nacs/penner'

on the same dirs as above, so it seems to be related to the -W flag.

So far i seems to be only the 1st partition file that's affected, and all the lines in that file are affected in the same way.

Any ideas?

[hjmangalam]

Another data point - in another trial, ALL the partition files were the same, but different than what I just wrote: Instead of starting as 'penner/etc', all of them started with 'nacs/penner/' (again, using the Perl-driven command, with the -W flag). And in another, the were all fully qualified. Very odd.

[martymac]

Hello Harry,

Hmmm, I could not reproduce the issue here (on a FreeBSD machine). Also, I cannot make a link between that behavior and the -W switch as partition files have already been written to disk (!).

That might be related to fts code, but that problem would then also be triggered in non-live mode or without the -W switch.

Here are things that you can try :

• use embedded fts code (FreeBSD one) by recompiling fpart with --enable-embfts option
• turn on debugging output by recompiling fpart with --enable-debug and check displayed paths

Best regards, Ganael.

[hjmangalam]

Thanks! Will do. Harry

On Thu, Apr 8, 2021, 3:16 AM Ganael Laplanche @.***> wrote:

Hello Harry,

Hmmm, I could not reproduce the issue here (on a FreeBSD machine). Also, I cannot make a link between that behavior and the -W switch as partition files have already been written to disk (!).

That might be related to fts code, but that problem would then also be triggered in non-live mode or without the -W switch.

Here are things that you can try :

• use embedded fts code (FreeBSD one) by recompiling fpart with --enable-embfts option
• turn on debugging output by recompiling fpart with --enable-debug and check displayed paths

Best regards, Ganael.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/martymac/fpart/issues/30#issuecomment-815639874, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASF3YZVIFVGCCKFKZ3N5S3THV665ANCNFSM42RXX4TQ .

[martymac]

Hello Harry,

Any news on that bug report ? Have you been able to perform additional testing ?

Best regards,

ganael.

[hjmangalam]

Hi Ganael, Apologies for the delay - I've been testing it semi-continuously and I haven't been able to make it misbehave since then, so I'm happy to think that it was me misfeeding it or having multiple fparts write into the same location (I was working on the parallel pfp, so multiple pfps could have been mistakenly writing to the same location). Let's call it a misreported bug until I can prove otherwise. Thanks as always. Harry

On Sun, Apr 25, 2021 at 9:35 AM Ganael Laplanche @.***> wrote:

Hello Harry,

Any news on that bug report ? Have you been able to perform additional testing ?

Best regards,

ganael.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/martymac/fpart/issues/30#issuecomment-826352079, or unsubscribe https://github.com/notifications/unsubscribe-auth/AASF3Y4GIEC4OIBEAX3VL4LTKRADPANCNFSM42RXX4TQ .

--

Harry Mangalam

[martymac]

Hello Harry,

OK, no pb :) I'll close the bug, feel free to reopen it if it happens again!

Best regards, Ganael.