Getting double folders - /usr/ and /usr_1/ on custom tcz

[Rich]

Hi jazzbiker

... Maybe my 2 cents are misplaced, but for slow flash drives sync doesn't guarantee that data have found their place, and sometimes those sleeps are the only way to success. ...

Taking a look at this:
https://man7.org/linux/man-pages/man2/sync.2.html

It states:

NOTES         top

       Since glibc 2.2.2, the Linux prototype for sync() is as listed above,
       following the various standards.  In glibc 2.2.1 and earlier, it was
       "int sync(void)", and sync() always returned 0.

       According to the standard specification (e.g., POSIX.1-2001), sync()
       schedules the writes, but may return before the actual writing is
       done.  However Linux waits for I/O completions, and thus sync() or
       syncfs() provide the same guarantees as fsync called on every file in
       the system or filesystem respectively.

To me that says that even if  sync  returns right away, Linux will wait for any current I/O to complete before starting any new
commands. Typically  sync  is used to flush cached writes to disk so it an be unmounted or to shutdown the system.

Take for example this:

Code: [Select]

else
sudo mv -f /mnt/mmcblk0p2/tce/mydata.tgz /mnt/mmcblk0p2/tce/mydata.corrupt
sleep 1
sudo mv -f /mnt/mmcblk0p2/tce/mydatabk.tgz /mnt/mmcblk0p2/tce/mydata.tgz
sleep 1
sync
sleep 2
sudo reboot
fi That first sleep is unnecessary. Linux will not execute the second  mv  command until the first one has completed.

If you did this:

Code: [Select]

sudo mv -f /mnt/mmcblk0p2/tce/mydata.tgz /mnt/mmcblk0p2/tce/mydata.corrupt &
sudo mv -f /mnt/mmcblk0p2/tce/mydatabk.tgz /mnt/mmcblk0p2/tce/mydata.tgz &you could have a race condition and I don't know what will happen.

As for the other 2  sleep  commands and the  sync  command, I'm pretty sure the  reboot  command calls  sync  too.

As an experiment, I copied a large file to a thumb drive (/mnt/sdh). Then in another terminal I monitored the busy file for the device:

Code: [Select]

cat /sys/block/sdh/device/device_busyThis always returned  1  while the  cp  command was active. It also returned  1  after  cp  command completed. I then issued
a  sync  command. It did not return for about 10 seconds. The  device_busy  file did not get set to zero until the  sync  command
completed.

[xor]

look at the visual diagrams
https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

https://en.wikipedia.org/wiki/Symbolic_link
https://en.wikipedia.org/wiki/Hard_link

Hi there Forum,

I seem to be going in circles with making a custom TCZ that will place a boot script in the /usr/local/tce.installed/ directory that runs md5sum check on the mydata.tgz backup file.

The issue is not that the tcz isn't loading, but for some reason I am getting a 2nd copy in a duplicate foler called /usr_1/ - seems very odd.

Example :

snb@snb:~$ md5sum /usr_1/local/tce.installed/md5mydata
baffab92405c6f437de2e7653dc523b4  /usr_1/local/tce.installed/md5mydata

snb@snb:~$ md5sum /usr/local/tce.installed/md5mydata
baffab92405c6f437de2e7653dc523b4  /usr/local/tce.installed/md5mydata

Both folders have my exact script and md5 shows the files are identical - I don't know how maybe I have told it to load twice?

By squashfs folder path is all in order from what I know as :

/squash-root/usr/local/tce.installed/md5mydata

Any suggestions on how I fix this issue?

BIG Thanks.

[Rich]

Hi xor

look at the visual diagrams
https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html

https://en.wikipedia.org/wiki/Symbolic_link
https://en.wikipedia.org/wiki/Hard_link

The problem that  onelife  was experiencing has nothing to do with  hard  or  symbolic  links.
If you read reply #1 by Juanito, he identified the cause of the problem and a solution.
If you read reply #2, I posted an alternate solution.
If you read reply #3 by onelife, he confirmed that his problem had been solved.

[jazzbiker]

Hi, Rich!

Thnks for testing my suspicious statement

for slow flash drives sync doesn't guarantee that data have found their place, and sometimes those sleeps are the only way to success.

This sentence consists of the two statements, in fact.

1. "for slow flash drives sync doesn't guarantee that data have found their place" - it is false statement. I've found very slow 4 class SD card and made some tough tests upon it and now can fully agree with You, that sync does its job very well. And more, I feel much more comfortable dealing with flash devices Of course I was not modelling power faults and other horror movies, but probably excessive sleeps will not heal the hardware and physical issues.

2. "sometimes those sleeps are the only way to success" - this is true statement at least for one scenario, which I cited from tc-install.sh and which I faced myself. Repartitioning of connected device needs some time for udev to recognize newcomers, and there is nothing to do with this but wait. But this is very special case and sync is out of suspicions, really. I don't know are the other such scenarios existing, it will be good to know about.

Thanks again for shooting my suspicions! Life becomes better when they're gone