Thanks, Albert, for this excellent and detailed bug report. I'll be able to test this now. We
might have a line on what the bug is.
Regardless of whether the user said to remove all shares or just the current share, the remove
file operation _shouldn't_ delete the source file. A remove file operation keeps the source file
intact so it can potentially be restored later. In other words, this is not user error. I'll look
into the issue and see if I can recreate it.
> Hello, Rob.
> I was as surprised (and, probably, "incredulous" about the cause) as you about
> the problems Kevin Cloudt and his team had with some missing files in the
> repository. Perhaps as a punishment by the gods, however, we've suffered
> something similar in our office: When trying to get a shared file, the client
> would warn about an IOException from some locations, and about a missing file in
> the server (providing the full path) from others. The corresponding source file
> is, obviously, really missing, so either it wasn't created when it was added or
> it was deleted sometime, without SJ updating its file system structures (as it
> still appears in the client interface, and the XML files still exist).
> Fortunately, the file had not been added long ago, and the person who has been
> working with it remembers all he had done with it:
> - First, it was added to the repository, of course.
> - Then, a file share was created to a different directory.
> - Some days later, a new share was added to yet another location.
> - Right after that, this latest share was removed.
> - Finally, some six new shares were created in various locations.
> And now, when you try to download the file, the error occurs as the source does
> not exist.
> The plugin activity logs confirm these actions, but with a special, suspectful
> and very intriguing difference: The fourth operation is logged as "remove-file",
> not as the expected "remove-file-share". And why?
> Well, the person who did it says he didn't choose the "Remove File Share" option
> from the menu, but the "Remove File(s)", which asks you whether you want to
> remove just this share or all of them. He clicked on the "Remove from this
> folder", which should be equivalent to "Remove File Share" (shouldn't it?).
> However, the server didn't log it as the same, and I believe that deleted the
> source file.
> You may say: "Well, who knows if he really clicked that button and not the other
> one?". Well, if he did so, then there's an error anyway, because ALL the shares
> should have disappeared and the file should not be visible anymore in the
> Therefore, my guess is that there's a bug in the removal of a file share by
> means of the remove file option. I ought to have checked that with some test
> files (which would have been much shorter than writing this looong email),
> but... well, I admit it, I'm too lazy.
> May Kevin's problems have the same origin? I hope they do, so they would be more
> easily solved.
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________
> SourceJammer-devel mailing list
> SourceJammer-devel@list... > https://lists.sourceforge.net/lists/listinfo/sourcejammer-devel >
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around