[Carruth, Rusty]

Have you actually tried copying files in use by the system?  I’ve never had trouble copying FROM an in-use file, and the only time I’ve had problems copying TO an in-use file (that I remember right now, but something in the back of my head is bothering me J) – anyway, the thing I remember about copying to an in-use file is that, if the new data is different than the data already in the file, and the file is an executable or a library which is in use,  you will usually core dump the executable(s) which is (are) running using that file.  However, as you can see below, ‘newer’ Linuxes apparently keep you from writing to a file which has a running program associated with it.  IIRC that is ‘new’ since 0.94 ;-)

 

Now you’ve said it so many times, I had to go test it myself, because I was certain that, in the normal case, you can copy an in-use file somewhere else:

 

rusty at rc-test1 ~ $ emacs sleeper.c

rusty at rc-test1 ~ $ ./sleeper &

[1] 25182

rusty at rc-test1 ~ $ ps  # see that sleeper is running

  PID TTY          TIME CMD

25049 pts/20   00:00:00 bash

25182 pts/20   00:00:00 sleeper

25183 pts/20   00:00:00 ps

rusty at rc-test1 ~ $ cp -p sleeper sleeper2   # copy executable from running sleeper to new sleeper2

rusty at rc-test1 ~ $ ./sleeper2  # run it.  Oops, forgot the ampersand

^Z

[2]+  Stopped                 ./sleeper2

rusty at rc-test1 ~ $ bg  # back ground it so we can see the ps list

[2]+ ./sleeper2 &

rusty at rc-test1 ~ $ ps   # yep, now we’ve got 2 of them running

  PID TTY          TIME CMD

25049 pts/20   00:00:00 bash

25182 pts/20   00:00:00 sleeper

25193 pts/20   00:00:00 sleeper2

25194 pts/20   00:00:00 ps

rusty at rc-test1 ~ $ cp sleeper2 sleeper   # ok, lets try copying sleeper2 on top of sleeper.

cp: cannot create regular file `sleeper': Text file busy

rusty at rc-test1 ~ $ 

 

So, you can copy the file TO a new place, but not overwrite.

 

So, I’m still lost as to why it won’t work to copy ‘all of’ /bin to a new directory, say ‘/bin.new’.  That process should happen with no issue (ignoring possible space issues, which could make life a bit harder, but not impossible).  So, now you have a new /bin.new.  ‘mv’ is in /bin, so in order to do the next step, you need to use the full path to mv: mv bin bin.old && /bin.old/mv /bin.new /bin  

 

And then your bin is new, as it were J.  

 

At this point, any programs which are running from /bin are using the /bin.old image.  You COULD actually delete bin.old, and the OS would keep the space for the in-use files as unavailable for use until you restart the program (which would then make it run from the new /bin copy).  Once all references to the file are gone, the space it occupied on disk would then be freed.

 

Wish I had time to set up a scrap system to try that on…  Which, by the way, is probably a good idea – set up a test system that is as close to your final system as possible (which might simply be ‘runs Linux’, don’t know) and try the various things to see how well they work and if they have any issues.

 

(should you have to copy a subset, then softlinks may be the easier way to go.  I’ll have to think about that a bit if your space is that limited.)

 

And for different reasons DD is probably not the right choice, unless it works to ‘dd /dev/foo /dev/foo’, which scares me a bit J (but actually might work.  Hmm…)

 

On the other hand, it sounds like this is not a normal filesystem, so ymmv!

 

 

From: plug-discuss-bounces at lists.phxlinux.org [mailto:plug-discuss-bounces at lists.phxlinux.org] On Behalf Of Mike Bushroe
Sent: Tuesday, May 13, 2014 11:57 PM
To: plug-discuss at lists.phxlinux.org
Subject: 

 


…. And some of the files in /bin and /sbin might be open and in use while trying to do the update, which is what has me going around the long way around.

I would be afraid of using dd because of the bad blocks. Although yaffs puts all the directory and file data for each page in the out of band bytes for each page, so that you could copy each page somewhere else and it would still work, that still seems a bit risky. If we use the file functions through yaffs, it will not only work around any bad blocks, but also increment the 2 bit page counter so that it can tell which page is current if power drops suddenly while the old and new versions are both still resident. And it will also mark the old pages as deleted and erase blocks where it can, so that should cover more ground than using dd directly. However, I have used dd to read the binary image of the flash, including the OOBs. But I have not yet decoded them enough to write a script to duplicate the processes in yaffs.

Mike

-- 

"Creativity is intelligence having fun." — Albert Einstein

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phxlinux.org/pipermail/plug-discuss/attachments/20140514/13a6ffa5/attachment.html>