In a script to access a plugin memory card, I received help and wrote a script. It used a sync command after unmounting the memory card.
umount /mnt
#flush buffers to make sure all the data is written to the SD card
sync
In the scanvirus script, I mount and unmount drives in the scanning process. It can include flash drives. Do need the sync command after unmounting a drive?
Yes the order of the commands should take care of the execution since sync comes first but you can probably add some message to the screen while sync is not done yet.
until sync; do
printf 'Still wainting for sync to finish.%s
'
done
You can play with it by negating the exit status of sync. It should give you the message…
until ! sync; do
printf '"I am Groot"%s '
sleep 5
done
Yes the order of the commands should take care of the execution since sync comes first but you can probably add some message to the screen while sync is not done yet.
until sync; do
printf 'Still wainting for sync to finish.%s
'
done
You can play with it by negating the exit status of sync. It should give you the message…
until ! sync; do
printf '"I am Groot"%s '
sleep 5
done
#if drive mounted, unmount it
#printf "Device_Mounted_Flag = %s Device_Label= %s
" $1 $2
if "$1" = 'true' ];then
#flush buffers to make sure all the data is written to drive
sync
command_output_unmount=$(udisksctl unmount -b "$2");unmount_error=$?
printf "%s
" ${command_output_unmount%.}
fi
I read the sync help file. Do I need to add the drive system to the command?
If one or more files are specified, sync only them,
or their containing file systems.
-d, --data sync only file data, no unneeded metadata
-f, --file-system sync the file systems that contain the files
–help display this help and exit
–version output version information and exit
It looks like you can specify files and have it sync just that filesystem;
you do not NEED to do this, but it may be better if you want your script
to run faster since then you will only sync the one soon-to-be-unmounted
filesystem instead of all filesystems of the computer.
On another note, I do not think sync will have that much to do unless you
are writing data to the filesystem about to be unmounted. Also, I do not
think umount will return until the implicit flushing of caches happens
anyway, but verify that is the case.
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
The scan includes flash drives. So to play it safe, I’ll use it. Is this correct usage?
#if drive mounted, unmount it
#printf "Device_Mounted_Flag = %s Device_Label= %s
" $1 $2
if "$1" = 'true' ];then
#flush buffers to make sure all the data is written to drive
sync -f "$2"
command_output_unmount=$(udisksctl unmount -b "$2");unmount_error=$?
printf "%s
" ${command_output_unmount%.}
fi
Looks okay to me. If I were you I would use the longer version of the
parameter for self-documenting purposes, particularly as it is a newer
option to ‘sync’ which may need to be looked-up otherwise:
–
Good luck.
If you find this post helpful and are logged into the web interface,
show your appreciation and click on the star below.
If you want to send me a private message, please let me know in the
forum as I do not use the web interface often.
Don’t forget to write error-handling.
As noted, sync isn’t really necessary because if there is a file operation i progress it has to be completed before the next command can execute.
But,
If a file operation hangs,
That’s one of the most common reasons for unsuccessful unmounts because typically the reason for the hanging isn’t known.
Maybe you can do a <file copy> instead of <move> and do a file comparison(diff)… If that succeeds verifying the file integrity, then you can <remove> the file source (if it’s a move operation) and then <forcibly unmount> because only then you can be sure the file operation has completed and really don’t care if the remove operation is successful or not (It probably would be because it’s a local file operation).
The above supports the idea of atomicity, and ensures the file operation is completed and successful first so that you can safely forcibly dismount even if the mount hangs for some unknown reason.
Note that sync is different than the operations I described and won’t fulfill your need.
Currently open files are handled. If the drive is already mounted, it’s not unmounted. Moving a currently open file doesn’t usually happen since windows is where I need to mount and unmount drives.