ARGOSY - HD363N - Network Storage

[HalRogers]

Problem: Formatting a QUANTUM 20 MB (a few years old), trie
formatting with FAT32 before use, also removing partition info
nothing worked.

Solution: Used a newer 120 GB Western Digital drive, removed th
Partition info, put into the HD363N, told it to format and the forma
was almost instant

Noise: Some say the drive is "noisy" -- it's the fan. Could probabl
reduce that noise with a resistor in series with the fan

Sleep Timer - Fan on/off: Some mentioned that the fan never goes of
even after the sleep timer expires (5 or 10 minute timer you set t
spins down the drive) - maybe that was the case at one time, but th
firmware 1013 stops the fan when it stops the drive

SetEOF Problem: I saw one problem reporti not recognizing the SETEOF
that's a programming issue that has no bearing on using the drive a
file storage and retrieval

I have had no trouble editing files that reside on the drive, and the
have to open and close the files and seem to do so without problems

-----------

So, bottom line, use an up-to-date drive to avoid formattin
problems

I like the ability to set the FTP port being used, which means I ca
have an FTP server listening on port 21 (my Buffalo-Tech Terrabyt
device) and on port 2100 (where I have this HD363N drive)

Ha

 

[dilettante]

SetEOF Problem: I saw one problem reporti not recognizing the SETEO
- that's a programming issue that has no bearing on using the drive a
file storage and retrieval

"Programming" issue? Indeed so, and one in which the firmware fail
to properly implement a fundamental SMB operation. If you use th
device as a file server with anything but trivial client software i
is also one that'll bite you sooner or later

Those who can get by treating the NAS as some sort of dum
file-by-file backup device will probably never experience it. If yo
try to use it as an actual file server though you're just a heartbea
away from a failure. Any software that updates a file in place ha
the potential to trip over this bug. Programs that perform fil
updating using simulated "tape to tape" operations creating a whol
new file on each update will be immune. Reports suggest Win9
versions of NotePad work that way

I would not be surprised to see file archivers or other mor
sophisticated backup utilities fail for this reason

This is a real bug, and seriously limits the use of this produc
outside hobbyist scenarios. I know it has kept my units benche
instead of being deployed. If they fail with NT4/Win2K/XP NotePad
can't begin to trust them in the wild

That said, in other ways the product performs quite well. I hav
about 1200 hours of continuous operation on one unit without
restart

 

[HalRogers]

As dilettante wrote ""Programming" issue? Indeed so, and one in whic
the firmware fails to properly implement a fundamental SMB operation
If you use the device as a file server with anything but trivia
client software it is also one that'll bite you sooner or later.

dilettante also wrote "This is a real bug, and seriously limits th
use of this product outside hobbyist scenarios. I know it has kept m
units benched instead of being deployed. If they fail wit
NT4/Win2K/XP NotePad I can't begin to trust them in the wild. "

Perhaps an example of the failure using notepad would be useful.

Clearly nobody wants a hidden failure lurking that will cause los
data. I've experienced network errors with bad NIC cards as well
which might point to some other hardware issue somewhere, no
necessarily the firmware in the unit itself. The jury may still b
out ?

So far, having saved numerous files, edited files, downloaded files
etc., to the drive, and using it as an FTP server for a while, i
seems to work fine. Also, it has a relatively unique ability to allo
both Anonymous FTP and user account/password FTP. For the price, it'
got a lot of features

If the SetEOF issue is indeed narrowed down to the firmware, and no
some other potential hardware issue, it would be nice to have a wa
to duplicate the problem and get some other users to verify it. S
far, I think (and I might be wrong) the only person reporting thi
"bug" is dilettante. As they say, one Robin doesn't make it spring
But two or more might be indicative of something

Ha

 

[segbert]

I have independently replicated dilletante's SET EOF bug

When using W98se and notpad I cannot replicate the problem
When using Linux and KWrite I cannot replicate the proble
When using W2k and notepad, I CAN SOLIDLY replicate the problem
I have not tried XP

When I get a chance, I will boot up a Live Linux CD in the W2k machin
and see if it replicates using Linux through the same hardware

 

[fixuser]

HalRogers
Please see [b:3de617d56d]dilettante[/b:3de617d56d]'s post on Sun Se
11, 2005, in this thread, in which he clearly describes how t
reproduce the end-of-file error

In general
I've continued to test for this issue with other editors. To date
the only other editor that can produce the same result is Ope
Office's Writer. If I edit a text file, not in Open Office forma
but just text, the same way as is suggested in Notepad, I get th
same result. But, if I edit a text file with other editors, I am no
able to produced the same outcome ... the files look fine

To be best of knowledge, this issue was reported to both Argosy an
Tritton, and subsequently confirmed by both, before the 6-101
firmware was released. Thus, I believe they have not yet found th
root cause

 

[fixuser]

segbert
When you run Linux, perhaps you could run Open Office's Writer to edi
the text file (remember to save the file in text format, not Ope
Office's file formats) and see if the error occurs. Maybe you shoul
do it running Open Office in Windows first, just so you know you ca
create the error with Open Office
At this exact momment, I'm not sure if I was running Open Office 1.
or 2.0 when I tested ... but, I'm guessing it was 1.5

 

[segbert]

Here is my test procedure

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 line
of
*******************************************************
I went through and added the line number to the beginning of eac
line
136*******************************************************
This was the most tedious part
This produced a test file of about 18k consisting of easil
identifiable lines

2.Save the test file to the NA
3.Open in Notepad,
After line 50, add 10 lines of 84 characters each
Save and close Notepa
4.Open in Notepa
delete the 10 lines added in step #
save and close noptepa
5.Open in notepad
examine the end of the file
With W98 & Linux it was O
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****..

 

[HalRogers]

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

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

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

I mapped a drive letter to a directory on the HD363N, the
Start/Run/CMD and switched to the drive letter and used EDIT to edi
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 th
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 b
truncating the size correctly, as other text editors do

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

Bottom line: Don't use Notepad.

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

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

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

Ha

 

[fixuser]

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

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

I have tried the same text editing operation with Notepad on othe
disks operating in my network
- NTFS formated disks inside a PC running Windows X
- 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 EXT
file driver

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

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

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

 

[benjamintm]

Hmm, well obviously I broke something flashing the newest firmwar
. Anyway, when my NAS trys to power on, it immediatly shuts bac
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
Be

 

[segbert]

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

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

 

[winux]

Segbert

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

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

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

 

[winux]

Segbert

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

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

Still trying to figure that one out..

 

[dilettante]

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

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

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

 

[HalRogers]

I think the issue boils down to setting the "filesize" attribut
correctly. I use UltraEdit and it has no such problems, whereas whe
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 th
file remains, ONLY because the subsequent reading of the fil
continues based on the number of bytes reported in the filesize

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

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

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

Thhen after closing the file, exiting EDIT, I re-ran EDIT, deleted th
inserted lines, closed the file, existed EDIT, and the DIR comman
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, i
may be using a form of file close, but not a generic file close tha
works correctly

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

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

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

Ha

 

[HalRogers]

I think the issue boils down to setting the "filesize" attribut
correctly. I use UltraEdit and it has no such problems, whereas whe
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 th
file remains, ONLY because the subsequent reading of the fil
continues based on the number of bytes reported in the filesize

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

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

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

Thhen after closing the file, exiting EDIT, I re-ran EDIT, deleted th
inserted lines, closed the file, existed EDIT, and the DIR comman
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, i
may be using a form of file close, but not a generic file close tha
works correctly

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

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

Ha

Then I use

 

[fixuser]

HalRogers,
I still believe the text file end-of-file issue has more to do with
the Argosy/Tritton NAS.

Like you, I had tried many applications, and as I previously posted,
was able to reproduce the outcome we all have verified with Notepad
also with Open Office. Tonight, I verified that again. Using the
exact same procedure in all applications, I saw the same outcome with
Notepad, OpenOffice 1.1.3 and OpenOffice 2.0. Now, its possible that
all these applications close the file in a manner that creates an
issue ... but I don't believe that to be the case. My reasoning is
that I cannot reproduce this end of file issue under any other
circumstances.

I have tried ALL of the following (which took some time), and none of
these configurations cause any problems.

- IDE connected hard disks formated to NTFS and FAT32 running Windows
XP
- USB connected hard disk formated to NTFS and FAT32 running Windows
XP.
- taking the FAT32 formated hard disk out of the Argosy/Tritton NAS,
IDE connecting it in the WinXP PC, and writing directly to it.
- writing to a FAT32 formated USB Flash drive connected to PC running
WinXP.
- writing to a NTFS formated hard disk being shared out by another
WinXP PC.
- writing to a EXT3 formated hard disk being shared out by a Linksys
NSLU2 NAS.
- writing to an EXT3 formated hard disk connected to a WinXP via USB
and interfaced to via EXT2 file driver for windows (see
http://www.fs-driver.org/ if interested).

The ONLY place I can create this end of file error with these
applications is when saving the file to the Argosy/Tritton NAS.

If the issue has to do with how Notepad, OpenOffice 1.1.3 and
OpenOffice 2.0 all close their files, how is it I can only produce
the issue when saving the file to the Argosy/Tritton NAS?

 

[fixuser]

General Request for Help
Since the 06-1013 firmware came out, I've had serious issues with the
NAS copying large directories to it. For example, a directory with
which I regularly have this issue is: 2.07 GB in size, has 6,819
files, and 848 directories ... it is a collection of program install
files, so the files range in size from very small to many tens of
MB.

When I attempt to copy this directory from the PC to NAS, at some
point along the way, I receive a Windows popup error window that says
"Error Copying File to Folder", "Cannot copy <filename>: The
specified network name is no longer available." Now comes the
seriousness of the issue, at this point the NAS can become
unresponsive. I can no longer access files on its disk, I cannot
access its web page, I cannot turn it off, I cannot reset it by
holding the power button in for a long time. I eventually have to
unplug the unit.

And, if I repeat this several times, it never seems to have the issue
with the same file. When I get the Windows popup error window, every
time there is a different file name in it.

And, it isn't every time that the NAS becomes completely locked up,
requring the plug to be pulled. Sometimes I can turn it off by just
hitting the power button.

Would anyone be willing to try copying a large directory a few times,
like the one I described, to see if you might generate the same
outcome?

I'm running Windows XP from the PC that I'm copying the files from.

If I look at the log file on the disk in the NAS, it doesn't show any
signs of an error or issue. The last entry in the log file is its
attempt to write the named in the popup window.

This is happening with both Argosy and Tritton devices.

 

[fixuser]

Another Tritton/Argosy Like NAS w/ USB
I noticed that CoolMax has a new Network Attached Storage device o
the market, mode
CN-550

Reading through its manual, it appears to have functionality very
very similar to the Trittona and Argosy devices. They don't have an
firmware updates listed on their site, so I can't yet compare th
firmwares

What's unique about this device is that it also incorporates a US
interface to the drive. That's a feature I would use

 

[segbert]

Fixuser

I got the same kind of error when I tried to copy a DVD-R full of m
install files to the NAS, almost 4 gb. I was using the 6-101
firmware and Windows 98

One other thing I noticed was while it was copying the DVD, ther
would be furious network activity for about 10 seconds, then it woul
pause for several seconds before resuming

Also:
There is unpopulated artwork for a USB connector on the circuit boar
of my HD363N. I was looking at it because I am thinking of mountin
the board and a removable drive bay in an old external 5 1/4 SCS
case so I can make use of all my old drives without buying a separat
NAS for each