| 1 |
I tried repeating your experiment, sans NFS and NTFS, and while I did |
| 2 |
note that the modification timestamp on the file did not change, the |
| 3 |
contents of the file did (i.e. the filesystem changed). |
| 4 |
|
| 5 |
FWIW this is Debian bug #459703 (Google told me that). |
| 6 |
|
| 7 |
What I'm going to guess is happening in your instance is the NFS server |
| 8 |
is caching parts of the file, and it checks the timestamp to see if the |
| 9 |
cache is dirty. Since it doesn't see that file file is modified it |
| 10 |
assumes its cache isn't dirty and continues to use it. |
| 11 |
|
| 12 |
You could possibly get away with it by simply |
| 13 |
|
| 14 |
# touch individual.files.img |
| 15 |
|
| 16 |
Maybe, maybe not. |
| 17 |
|
| 18 |
|
| 19 |
Also, usually you don't need to use losetup unless you are using |
| 20 |
encryption or offsets or something else exotic. Usually |
| 21 |
|
| 22 |
# mount -o loop my.img /mnt/pt |
| 23 |
|
| 24 |
Will do the trick. |
Archives