Re: Packing bug?

On Friday 11 February 2005 13:20, Matt Hamilton wrote:

> but I'm 
> guessing that somehow the same path comes up again 

That would do it.... I wonder how it happens?

On reiserfs, I assume? I understand that reiserfs opendir/readdir presents 
inodes in the order they are stored in the filesystem tree, which is 
basically the same as filename hash order. A renamed file might come up 
twice, but one that is not renamed should not. The files that we care about 
never seeing twice are not renamed, therefore this should be safe.

Conventional unix filesystems that use linear directory searches (eg ext2) can 
show a file twice if it is renamed to a longer name that does not fit in the 
old directory slot. Again, safe.

On other filesystems I can imagine this not being safe :-( It might also be 
unsafe if there are other concurrent changes in the same directory. 
DirectoryStorage is in snapshot mode at that time, but there could be 
external triggers.

Hmmmm, this does all seem uncomfortably close to a danger zone.

> So the above logic seems to say: 'if the file is marked and we are not in
> pretend mode, unmark it'.  Doesn't this seem a bit odd?  I assume this is
> such that all files are unmarked by the end of the packing, 

Yes, it is a performance optimisation. If we dont do it now, that bit will 
need to get flipped in pass 1 in the next pack (unmark_all, called from 
filesystem.mark_context). It is cheaper to do it sooner while the inode is 
already in memory.

It is a pure optimisation, so I think it would be safe to remove that branch. 
I will review this code later today to confirm this solution.

Thanks for the detective work. Good find.

-- 
Toby Dickenson

____________________

Important Notice:

This email and any attachments are confidential and may contain trade secrets or be legally privileged. If you have received this email in error you must not use, rely upon, disclose, copy or distribute the contents. Please reply to the sender so that proper delivery can be arranged and delete the email from your computer.
Gemini Data Loggers monitor incoming and outgoing email to ensure satisfactory customer service, maintain company security and prevent abuse of their email system. However, any views expressed in this email are not necessarily those of Gemini and Gemini cannot be held responsible for the content.
Gemini makes best efforts to ensure emails are virus free; however you are advised to carry out your own checks. Gemini does not accept responsibility for any damage resulting from email viruses.
____________________



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id396&op=click