svn co while emptying trash makes trash in checked out data

[Adek336]

svn co ​svn://svn.berlios.de/haiku/haiku/trunk /haiku-dane/haiku

while having another copy of the haiku trunk deleted from /haiku-dane

In effect, garbage can be found in the newly checked out data, for example, "svn stat" complains about garbage in svn control files.

I have been able to reproduce it on a via_rhine ethernet adaptor and not yet on a broadcom adaptor, it may be perhaps linked to long mbuf chains, also see #2840.

[Adek336]

So the data that were written to the disk don't get corrupt. Only the new data that are only now being written to disk get corrupt.

On a BFS partition, when you have say 30 files, each file 20 MiB, do a copy of them, wait a few seconds after Tracker has finished copying and press F12 and type "reb<cr>". After reboot, you can see the just copied files, although, they are corrupt. I suppose that BFS has got journaling and the newly copied files after a crash should be either present and not corrupt, or not exist at all.

[anevilyak]

Replying to Adek336:

On a BFS partition, when you have say 30 files, each file 20 MiB, do a copy of them, wait a few seconds after Tracker has finished copying and press F12 and type "reb<cr>". After reboot, you can see the just copied files, although, they are corrupt. I suppose that BFS has got journaling and the newly copied files after a crash should be either present and not corrupt, or not exist at all.

You seem to be under a slight misconception here: on the vast vast majority of filesystems, journalling guarantees nothing whatsoever with respect to the file data; all that is journalled is metadata operations, in other words, the journal is used to guarantee that the FS itself is internally consistent, i.e. if a file is created/destroyed/resized, it is guaranteed that all the underlying metadata operations (volume bitmap, B+Tree modifications, etc.) happened completely or not at all. The actual file block data is not journalled or guaranteed in any way, shape or form. The only filesystems that do this that I'm aware of are log-structured filesystems such as ZFS.

[axeld]

Indeed, BFS does not log file data, only meta data (it even has a "log file" flag (usually used for symlinks), but that is not working on our BFS anymore (since it has been ported to Haiku's file system API).

[waddlesplash]

Anyone seen this in the last 10 years?

[diver]

I think we would have run into this if it was still the case.