Updated timestamp on modified files is not being recorded

[picsinc]

I am using a ReadyNAS nv unit with Domain integration and RAIDiator™ v2.00c1-p7 [1.00a014]. My Domain Controller is Windows Server 2003 and my Desktop is Windows XP Pro SP2.

If I create a new file on the nv unit share, the current date time will be stamped on the file and subsequent changes to that file will reflect the last modified timestamp. Even when I make a copy of this file and then modify the copy, the modified timestamp is recorded correctly on the copy.

However, when I modify any files that have NOT been created explicitly on the nv share (i.e. by copying from another network folder), the modified date/time as reported by Windows Explorer will not change.

Also I noticed that in both cases, the changed attribute [A] was not turned on for any modified files.

This is a serious bug as I have no way of telling what files have been changed since they have been migrated to the nv unit. I cannot depend on either the timestamp or the file-changed attribute as both have not changed.

I do not know if this bug occurs only with Domain integration. I post it here only because I am using Domain integration.

[ewok]

I haven't been able to reproduce this issue. If I modify a file that was copied to a NAS in Domain mode via drag and drop, the timestamps are updated correctly. How did you move/copy these files to the NAS? When you modify them, are you sure the modifications are saved?

[picsinc]

Since I posted my inital message, I have also found that the timestamp for modified files are now recorded successfully. These include the ones that were having problems earlier. In one case, the modified date stuck at 11-19-2005 even though I kept changing it by adding blank lines to it and saving it 2 days ago. Today, when I added another blank line, saved it, and the date changed correctly to today's date. Having said that, I can still confirm that the problem did exist because I still have files that I modifed within the last 3 days but their modified dates are still in January 2006 or older. In fact, their modified dates matched the one in the original folder from which they were copied, even though the contents had changed.

Apart from the date issue which is now apprarently fixed, the "A" attribute indicating the file has changed is still not being set.

Before I posted my original message, I rebooted the device and that did not fix the problem initially. I also checked the date and time on the device and it was in-sync with my domain server. Since then, I had not rebooted the device but I did reboot my workstation and my server.

I did not use drag and drop as I was moving the entire share from the Domain server. Instead, I right clicked on the source folder and selected COPY and then I right clicked on the nv share and selected PASTE. The share currently has over 20GB of data with over 130000 files and 7000 folders.

[ewok]

The archive attribute not being set is a confirmed bug, and will be fixed in an upcoming release.

[picsinc]

When the problem occurred over the weekend, the share on the nv device was being accessed by another computer with read-only access. I was actually running WinPE (Windows Preinstallation Environment) with a non-admin account on that computer to silently install Windows XP while I was accessing the same share as an administrator with read-write access and monitoring the installation process. During the process, I actually had to change a couple of configuration files before the remote installaion would succeed. Thus I knew that my modifications had been saved and yet the timestamp did not change.

[ewok]

If you change those same files now, do the timestamps get updated?

[picsinc]

Timestamp is now updated correctly. However, I do not have a non-admin user accessing the share simultaneously.

[picsinc]

It happened again. I modified 10 text files using Notepad and none of their timestamp have changed. I am using the latest firmware. Something is just not working right.

[ewok]

Were the sizes of these files changed with your edits?

[picsinc]

They are mainly command scripts such as .BAT or .CMD or .INI., mostly under 1KB.

[ewok]

Did the size of the file(s) change when you editted them or did you just replace content with the exact same sized content?

[picsinc]

In the same folder, I edited 2 files. For the first one, I removed 10 bytes and saved it and its timestamp changed. For the second one, I added 48 bytes and saved it and the timestamp remained 2004-07-17. I will monitor other file changes and report back if I see a pattern here.

[ewok]

In the same folder, I edited 2 files. For the first one, I removed 10 bytes and saved it and its timestamp changed. For the second one, I added 48 bytes and saved it and the timestamp remained 2004-07-17. I will monitor other file changes and report back if I see a pattern here.

What happens if you make a copy of the file whose timestamp did not change, then make a change to the copy of the file? Does the timestamp change? If you change the original file again, does the timestamp change or stay the same?

[picsinc]

Per your request, I made 3 copies of the file REBOOT.BAT, which was the one that I added text and its timestamp remained 2004-07-17 and called them REBOOT1.BAT, REBOOT2.BAT and REBOOT3.BAT respectively. I deleted text from REBOOT1.BAT; added text to REBOOT2.BAT and changed text (file size did not change) in REBOOT3.BAT. Here is the pattern:

REBOOT1.BAT: Filesize decreased; Timestamp updated
REBOOT2.BAT: Filesize incresased; Timestamp remained 2004-07-17
REBOOT3.BAT: Filesize unchanged; Timestamp remained 2004-07-17

The pattern seems to suggest that the timestamp will update only if filesize has decreased.

[ewok]

A couple of more things to try:

1. Can you try editting these files with a different editor?

2. Give Everyone access to the reboot.bat files, then enable Web read/write access to the share. Access the share using your web browser (http://$hostname), then use the Web-based editor to make the same changes to the files (click the checkbox next to the file, then click Edit at the top of the page). Do the timestamps change?

These steps will help us narrow down the cause of the problem.