Philipp Börker schrieb:
When the media-player connects to a computer via USB, the local
harddisks must be umounted in order for the USB controller to take
over. Instead of umounting the unionfs, I simply remove the harddisk
directories from the unions and umount the harddisk afterwards.
Currently, I have eight unionfs and notice crashes and strange
behaviour when I remove those eight harddisk directories from their
respective unions...
Okay, just to work out a bit on this:
I have a root-filesystems that read-only. I add overlays from
directories on the media-players harddisk in order to make the
filesystem appear writable. When the media-player connects to a computer
via USB, the harddisk needs to be umounted and hence the writable
directory of the unions need to be removed. Of course, there may be
files opened for writing which is a problem. In fact, the media-players
operating system seems to always open some files and crashes when I
remove the writable directories.
Now: would it be possible to add a writable directory in a ramdisk to
the union first and then remove the writable harddisk-directory? Will
unionfs keep the same file open for writing? Will the data on the
harddisk be consistent when the harddisk gets added to the union and the
directory in the ramdisk gets removed? I'm not sure whether the problem
is clear. Here's an example:
I have a union set up like this:
mount -t unionfs -o dirs=/harddisk/unionfs=rw:/readonly=ro unionfs /readonly
Now some file /readonly/file gets opened for writing. The media-player
then gets connected to a computer and needs to umount /harddisk which,
of course, fails because /harddisk is busy.
Can I do this:
unionctl /readonly --add --before /readonly --mode rw /ramdisk/unionfs
unionctl /readonly --remove /harddisk/unionfs
umount /harddisk
[connect to computer, USB activity on /harddisk]
mount /harddisk
unionctl /readonly --add --before /ramdisk/readonly --mode rw
/harddisk/unionfs
unionctl /readonly --remove /ramdisk/unionfs
Will the file opened for writing remain open?
Thanks for your patience!
_______________________________________________
unionfs mailing list
[email protected]
http://www.fsl.cs.sunysb.edu/mailman/listinfo/unionfs
