Very Serious KeepSafe Flaw

Stardock unresponsive


I notified Stardock Support and Gripeline of this issue on 2006/11/27 and again on 2006/11/29. No response at all. Here is the issue:

Specs:

KeepSafe Trial, keepsafe_public.exe, downloaded Nov 10, 2006.
Windows XP PRO SP2.

Issues:

1) KeepSafe Archive unreliable due to fundamental implementation flaw issue:

KeepSafe stores file backups within the regular Windows file system in such a way that backups are subject to some surprisingly severe file system limitations. It's a well-known fact (at least to technicians) that in Windows the full path to a file cannot exceed 260 characters in length. The full path includes EVERYTHING: drive letters, colons, backslashes, all folder/subfolder names, plus the filename itself including any period and extension. As I will show in this post, the 260 character limit, combined with KeepSafe's default archive location, is effectively MUCH more restrictive than you think, and can routinely limit KeepSafe's effectiveness and can even result in KeepSafe not creating backups for many files at all! And unfortunately KeepSafe won't notify you when that happens.


For example,
suppose there's a file named "TheGrandCanyonAtNight01.jpg", residing at the path "C:\Documents and Settings\Richard\My Documents\My Pictures\Vacation 2006". Taken all together, the full path to the file is "C:\Documents and Settings\Richard\My Documents\My Pictures\Vacation 2006\TheGrandCanyonAtNight01.jpg". That full path is 100 characters long.

Of course 100 characters falls comfortably short of the 260 character limit, but in my experience that really is a rather short path. Many of us find that it doesn't take a very complex business, programming, or website project to require storing many files within many subfolders several levels deeper than my simple example. Still, the 260 character limit can usually be accomodated without too much inconvenience.

BUT, due to KeepSafe's method of archiving backups, backing up this file will add so much overhead to the path that it will bring even my simple example nearly to the point of breaking the 260 character limit.


Here's why:
The name of each backup file in the archive consists of: The original file name, including period and extension. + Two underscores. + A 10 character timestamp. + The period and extension again. In uppercase. In my example, one backup file might be named "THEGRANDCANYONATNIGHT01.JPG__1163820524.JPG". This will add 16 characters of overhead to the original file name.

All such backups for a particular file are then stored in a folder whose name is the original file name. In uppercase. In my example, the folder would be named "THEGRANDCANYONATNIGHT01.JPG". After adding a trailing backslash, this will add 28 characters of overhead to the path.

All such folders are then stored in a folder whose name is the path to the original file. Backslashes and colons are replaced with underscores. In my example, this folder would be named "C__Documents and Settings_Richard_My Documents_My Pictures_Vacation 2006". Even including a trailing backslash, this will add no additional characters of overhead to the path.

All of these folders are then stored in a folder whose name is the extension of the original file name. In uppercase. In my example, this folder would be named "JPG". After adding a trailing backslash, this will add 4 characters of overhead to the path.

All of these folders, one for each file extension backed up, are then stored in the KeepSafe backup archive. On my machine, this folder path is "C:\Documents and Settings\Richard\Local Settings\Application Data\Stardock\KeepSafeArchive". This is the default that KeepSafe created at install time. After adding a trailing backslash, this will add a whopping 91 characters of overhead to the path.

Putting all of this together, we get a surprisingly long full path to the backup file. In my example, it comes to this: "C:\Documents and Settings\Richard\Local Settings\Application Data\Stardock\KeepSafeArchive\JPG\C__Documents and Settings_Richard_My Documents_My Pictures_Vacation 2006\THEGRANDCANYONATNIGHT01.JPG\THEGRANDCANYONATNIGHT01.JPG__1163820524.JPG". That full path is 239 characters long, and uncomfortably close to the 260 character limit!


So what
happens when the 260 character limit is exceeded? KeepSafe reliability declines drastically or disappears altogether, depending upon full path length, path length, and file name length.


One scenario will go something like this:
If the path length (full path length minus the final backslash and file name length) is less than 260 characters, KeepSafe will progressively lose it's abilities. The loss will depend upon file name length.

First to go will be KeepSafe's ability to recover a file from it's backup archive. You won't be notified. At recovery time your file simply won't be restored! You'll just have to figure out the hard way that your file hasn't changed!

Second to go will be KeepSafe's ability to even create a backup file in the first place. The KeepSafe backup process will create a folder for the file's backup, but will not be able to create the actual backup file itself. You won't be notified. At recovery time you'll discover that the file's backup folder is empty!

Last to go will be KeepSafe's ability to even create a place to create a backup file. The KeepSafe backup process will not even be able create a folder for the file's backups, and of course backup files won't be created either. You won't be notified. At recovery time you'll simply find no trace of your file anywhere in the KeepSafe backup archive!


Discovery of this flaw started as a theory. Considerable testing on my KeepSafe trial installation supports my theory. This flaw is a fact.


What should be done?
Various workaround strategies can be devised to limit the situations where this flaw will be exposed, but this will remain a dangerous issue. My unsolicited advice to StarDock is this:

1) Own the problem.
Warn registered customers via email.
Warn trial and potential customers via the forum.
2) Patch KeepSafe to anticipate the 260 character failure point.
User should be notified as a failure point is reached.
3) Make the patch available to all customers ASAP.
4) Fundamentally revise the KeepSafe Archive method.



2) KeepSafe "delete all revisions" failure issue:

Due to full path length problems described in issue #1, entries can be created in the KeepSafe archive which cannot be deleted! This can come into play when "delete all revisions" is selected to empty the KeepSafe backup archive. How to get rid of these files?



3) KeepSafe Archive remains after uninstall issue:

Due to full path length problems described in issue #1, KeepSafe uninstall cannot fully delete the KeepSafe archive. My archive contained some files whose full path was too long to delete, so the KeepSafe uninstall simply left them behind! I shortened file/folder names, then deleted them manually.


The KeepSafe concept is a good and valuable one. I want to use KeepSafe, but due to this flaw, I will not. I hoped that Stardock had enough confidence in their product to defend it or fix it, but they've had this information for 5 business days and have remained utterly silent about it. That's very unfortunate.

DocDay


21,042 views 9 replies
Reply #1 Top
they've had this information for 5 business days and have remained utterly silent about it.


Not even a peep after following the 'follow up' instructions in the auto-reply?

No status at the help serve?


So if MS fixed the 260 limit there would be no flaw, no?

Reply #2 Top
So if MS fixed the 260 limit there would be no flaw, no?


LMAO! How long has this bug been known? I haven't gotten my warnign email from MS yet!

It a good bug report, but the problem is not very likely and is probably being prioritized and handled. Relax.   
Reply #3 Top

Did you consider the mail may not have been even looked at yet?  I checked the support queue myself and it does seem that it has yet to be processed.  This is probably because support have been asked to do some extra QA work this week on something we have been working on.

I am sorry they did not see it and I would have hoped they would at least keep an eye out for important issues as well.  Sending the 2nd reply actually would drop you back in the queue due to how esupport works.

Given how detailed your mail is, I would have expected the support response to have been to say they were forwarding it to development which in this case would be myself.

I have had a quick look and as a short term workaround, you could set the KS storage location to have a shorter path.

If KS is unable to write a file to disk it will display a warning notification.

BTW the maximum length of a filename on NTFS is not 260 chars.  It is 32K in length.  Explorer is unable to handle such long paths, but you can create them using CreateFileW and the \\?\ prefix.

I will take a look next week to see which calls in KS are apparently getting upset by this limit.  I know that this will certainly be less of a problem in Vista due to the changes Microsoft made to the location of the users directories.

Reply #4 Top
It does seem that when a software house receives an email whose subject is of the form "Very Serious (productname) Flaw", quick action is in order.

To anyone who believes this flaw is unlikely to cause problems in ordinary circumstances, please carefully read the "For example" and "Here's why" sections of my original post.

During my investigation of this flaw no KeepSafe warning notification was ever issued. This is very disquieting behavior in a backup application.

My folder structures tend to run "deep and narrow" rather than "shallow and wide". The structure described in my "For example" section is much shallower than typical for me. Thus it seems pointless to manipulate the full path length by relocating the KeepSafe Archive. I'll probably still bump into the flaw fairly frequently, and KeepSafe won't notify me.

Yes, I understand that full path lengths much longer than 260 characters are possible in certain circumstances. KeepSafe may simply not understand it's circumstances.

DocDay
Reply #5 Top
I feel the need to note that we see lots of "Very Serious Flaw" posts and emails, with 99.9% of them being stuff like spelling errors. Obviously, this case actually qualifies, but I trust you can see how support tends to not rush to every email with that subject line.
Reply #6 Top
So, am I getting this right. If KS would run into this problem there will be a messagebox alerting me? Or will it silently fail? I'm somewhat concerned about that because I tend to have quite deep folder structure as well.
Reply #7 Top
I've been using the proggy for years....never struck the issue...probably because I have a far more sensible [and short] directory structure configuration than the 'MS-for-idiots' default one....
Reply #8 Top
Has this issue been cleared up yet?

It is now middle of 2007. I was thinking of buying, and thought I would check the forum, and came across this thread.


thanks,
Brian
Reply #9 Top

This issue was addressed with KS 2.0