If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#141
|
|||
|
|||
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****... |
#142
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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 |
#143
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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. |
#144
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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 |
#145
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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. |
#146
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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] |
#147
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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... |
#148
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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. |
#149
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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 |
#150
|
|||
|
|||
ARGOSY - HD363N - Network Storage
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 |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
SAN (Storage Area Network) Security FAQ Revision 2004/10/30 - Part 1/1 | Will Spencer | Storage & Hardrives | 0 | October 30th 04 08:35 AM |
SAN (Storage Area Network) Security FAQ Revision 2004/06/23 - Part 1/1 | Will Spencer | Storage & Hardrives | 0 | June 23rd 04 07:04 AM |
SAN (Storage Area Network) Security FAQ Revision 2004/04/11 - Part 1/1 | Will Spencer | Storage & Hardrives | 0 | April 11th 04 07:13 AM |
SAN (Storage Area Network) Security FAQ Revision 2004/02/16 - Part 1/1 | Will Spencer | Storage & Hardrives | 0 | February 16th 04 09:02 PM |
SAN (Storage Area Network) Security FAQ Revision 2004/02/12 - Part 1/1 | Voyager | Storage & Hardrives | 0 | February 12th 04 04:31 PM |