ARGOSY - HD363N - Network Storage

Here is my test procedu

1.Using Notepad, or whatever editor you are testing with,
I made a line of 84 asterisks,
I copied and pasted till I had a chunk of lines,
then copied and pasted bigger and bigger chunks till I had 200 lines
of
************************************************** ******
I went through and added the line number to the beginning of each
line:
136*********************************************** *********
This was the most tedious part.
This produced a test file of about 18k consisting of easily
identifiable lines.

2.Save the test file to the NAS
3.Open in Notepad,
After line 50, add 10 lines of 84 characters each.
Save and close Notepad
4.Open in Notepad
delete the 10 lines added in step #3
save and close noptepad
5.Open in notepad.
examine the end of the file.
With W98 & Linux it was OK
With W2k it was:

195****...
196****...
197****...
198****...
199****...
200****... (THIS SHOULD BE THE END OF THE FILE, BUT IT IS NOT)
****...
192****...
193****...
194****...
195****...
196****...
197****...
198****...
199****...
200****...

The experiment with using Notepad and inserting text and deleting
text, and ending up with junk at the end of the file, notice that the
junk at the end of the file is the text that was "pushed" there by
inserting text in the middle of the file.

Then you delete that text in the middle of the file, and draw back the
lines from end of the file. BUT, there is a copy of those lines in the
file itself from the previous push that remain there after lines are
deleted in the file.

Clearly, looking at the properties of the file, you can plainly see
that the file size is WRONG when using NotePad, but is correct when
using UltraEdit.

I mapped a drive letter to a directory on the HD363N, then
Start/Run/CMD and switched to the drive letter and used EDIT to edit
the file with the 200 lines in it.

I inserted 10 lines in the middle, saved the file (like in notepad).

Then closed and exited EDIT (an old program by the way)

Then ran EDIT on the text file, removed the inserted lines, closed the
file and exited, and it was as expected, with no junk at the end.

My conclusion: Notepad clearly does not properly close a text file by
truncating the size correctly, as other text editors do.

It would be helpful to know what Notepad is doing when it closes
files, but that would require more testing.

Bottom line: Don't use Notepad.

If you have problems with other programs, change the way you close
files.

Check the filesize (properties) of the file and see if it corresponds
to what you expect.

Do I think it's a bug in the firmware? Not really, it's more of an
expectation that software will properly close files.

Hal

HalRogers,
That's an interesting perspective ... to stop using an application, or
change how one uses an application, because of how the file server
stores the data. I can't say I agree with that approach.

I would consider data storage on a disk a rather fundamental process
that should work reliably, such that one should be able to just
assume it works properly in the background and not have to change or
adapt use of an application to overcome a limitation.

I have tried the same text editing operation with Notepad on other
disks operating in my network:
- NTFS formated disks inside a PC running Windows XP
- FAT32 formated disks in a PC running Windows XP.
- EXT3 formated disks running in a file server on the network.
- FAT32 formated disks running in a file server on the network.
- EXT3 formated disk running in a PC running Windows XP with an EXT2
file driver.

All of these work reliably. So, there is something happening in the
interaction with the HD363N that is not allowing the file from
Notepad to be stored/edited properly.

Even with the 'work around' you suggest, how do you know you won't run
into another application that cannot save the data properly ... it may
be too late before you find the file is corrupt. I think that's the
arguement [b:a36b491713]dilettante[/b:a36b491713] is trying to
present in that one does not know if you can rely on the product to
accurately store the files. (Not that I'm trying to speak for
dilettante, I just think I understand his/her perspective.)

I'm not saying I know for certain that the issue exists inside the
HD363N, but at the momment it is the only device for me that cannot
reliably pass this test of editing a text file using Notepad. Thus,
I think it warrants some investigation on behalf of the
manufacturers.

Hmm, well obviously I broke something flashing the newest firmware
:-). Anyway, when my NAS trys to power on, it immediatly shuts back
down. I'm thinking I did a bad flash. Any suggestions on fixing it?
I thought about using TFTP, but I can't figure out how/if it works.

Thanks,
Ben

Try making sure the hard drive is connected properly.
When I first got mine, I couldn't wait long enough to go dig through
the closet to find an old drive, so I tried to talk to it without a
drive in it. I seem to remember the light would come on for just a
second, but the power would not stay up. Once I put a drive in it, it
powered up just fine. I'd try the other of the master/cable select
setting to see if that helps. Also try a master reset using the
recessed reset button on the back. (specific instructions given
earlier in the forum).

Use IE when flashing the NAS firmware. While Firefox works fine
otherwise, it won't flash the NAS properly for me. It looks like it
flashed, but then it hangs waiting for reset, and the loaded firmware
remains untouched. Maybe it's some FF setting, but IE works fine for
me.

Segbert:

My Firefox updated the firmware just fine. Even my Mac using Safari
did, too. Odd....

Anyways, I did notice on Windows 2000 with IE or Opera (haven't tried
Firefox), that no matter what changes I made to the NAS, like a
reset, it seemed to always keep the previous settings. A quick call
into Tritton informed me that it was some kind of caching problem in
Windows 2000 and IE. So, with the User interface up on one computer,
I went to the next computer--Windows XP--pulled up the same
interface, and the new changes were there. I even refreshed the page
on Win2K a million times and the old settings appeared, even though
it was just cache.

Still trying to figure that one out...[/b]

Segbert:

My Firefox updated the firmware just fine. Even my Mac using Safari
did, too. Odd....

Anyways, I did notice on Windows 2000 with IE or Opera (haven't tried
Firefox), that no matter what changes I made to the NAS, like a
reset, it seemed to always keep the previous settings. A quick call
into Tritton informed me that it was some kind of caching problem in
Windows 2000 and IE. So, with the User interface up on one computer,
I went to the next computer--Windows XP--pulled up the same
interface, and the new changes were there. I even refreshed the page
on Win2K a million times and the old settings appeared, even though
it was just cache.

Still trying to figure that one out...

I've confirmed that Windows 95 NotePad saves over old files
differently that Windows 2000 and Windows XP NotePad does. The older
versions seem to write a whole new file, while newer ones rewrite into
the existing file on a SAVE operation.

Both of these are common ways to update a text file on SAVE. The
issue isn't NotePad, but the NAS firmware. Any given program that
updates files in place and later relys on the file's EOF pointer to
be accurate will suffer the same problem. My point is that the
formware needs a fix in this area, or else users can never know when
some arbitrary program they use might fail in a similar manner.
NotePad (NT versions) is just an example of a program one can use to
easily reproduce the symptoms of this bug.

I doubt a fix is going to be very difficult and so I'm a bit mystified
that this bug wasn't squashed fairly rapidly in one of the more recent
updates. Fixing it might fix a lot of nagging problems like the PST
file issues, either in itself or by pointing out some related
problems they might find while fixing this one.

I think the issue boils down to setting the "filesize" attribute
correctly. I use UltraEdit and it has no such problems, whereas when
I use Notepad to conduct the same set of tests as described earlier,
the filesize is not properly set, so the "junk" at the end of the
file remains, ONLY because the subsequent reading of the file
continues based on the number of bytes reported in the filesize.

Why does UltraEdit, or WordPad NOT have this problem, whereas Notepad
does have it?

Having been a Windows users for years, and a software developer for
more years, I think it's likely that Notepad is was not tested as
thoroughly as other software, or perhaps the right file closing
routines are not being performed by Notepad, hence the filesize is
not getting updated correctly.

I even tested this in DOS (Start/Run/Cmd) and used "Net Use" to create
a drive letter for one of the subdirectories. I ran EDIT (an old DOS
program that is part of every WIndows XP installation) created the
longer file version using the "insert lines" approach, and indeed it
was longer according to the DIR command.

Thhen after closing the file, exiting EDIT, I re-ran EDIT, deleted the
inserted lines, closed the file, existed EDIT, and the DIR command
correctly showed the filesize back to the original length.

Notepad does not do this.

So, my feeling is that Notepad is not properly closing the file, it
may be using a form of file close, but not a generic file close that
works correctly.

Bottom line: I'd attribute this to Windows "Notepad.exe" and the way
Notepad closes files. If a similar problem occurs with other
programs (and so far I haven't seen it) it's probably due to the
manner in which the file is closed.

So far EDIT, even EDLIN, UltraEdit, WordPad, and Word all close the
file properly, and can handle the experiment described in which
Notepad.exe fails to truncate the filesize.

Could it be a Notepad bug? It's clear that all the other text
editors, including EDLIN, perhaps the oldest one around (came with
the original PC DOS in the 1980s), properly close files and set the
file size, but Notepad is unique in failing to do so.

Hal

I think the issue boils down to setting the "filesize" attribute
correctly. I use UltraEdit and it has no such problems, whereas when
I use Notepad to conduct the same set of tests as described earlier,
the filesize is not properly set, so the "junk" at the end of the
file remains, ONLY because the subsequent reading of the file
continues based on the number of bytes reported in the filesize.

Why does UltraEdit, or WordPad NOT have this problem, whereas Notepad
does have it?

Having been a Windows users for years, and a software developer for
more years, I think it's likely that Notepad is was not tested as
thoroughly as other software, or perhaps the right file closing
routines are not being performed by Notepad, hence the filesize is
not getting updated correctly.

I even tested this in DOS (Start/Run/Cmd) and used "Net Use" to create
a drive letter for one of the subdirectories. I ran EDIT (an old DOS
program that is part of every WIndows XP installation) created the
longer file version using the "insert lines" approach, and indeed it
was longer according to the DIR command.

Thhen after closing the file, exiting EDIT, I re-ran EDIT, deleted the
inserted lines, closed the file, existed EDIT, and the DIR command
correctly showed the filesize back to the original length.

Notepad does not do this.

So, my feeling is that Notepad is not properly closing the file, it
may be using a form of file close, but not a generic file close that
works correctly.

Bottom line: I'd attribute this to Windows "Notepad.exe" and the way
Notepad closes files. If a similar problem occurs with other
programs (and so far I haven't seen it) it's probably due to the
manner in which the file is closed.

So far EDIT, even EDLIN, UltraEdit, WordPad, and Word all close the
file properly, and can handle the experiment described in which
Notepad.exe fails to truncate the filesize.

Hal

Then I used