This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Summary: | Moving a project does not preserve file and folder timestamps | ||
---|---|---|---|
Product: | platform | Reporter: | michaelmilette |
Component: | Filesystems | Assignee: | Jaroslav Havlin <jhavlin> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anebuzelsky, ovrabec |
Priority: | P1 | ||
Version: | 8.0 | ||
Hardware: | PC | ||
OS: | Windows 7 | ||
Issue Type: | DEFECT | Exception Reporter: | |
Attachments: | Partial Fix |
Description
michaelmilette
2014-05-04 22:20:39 UTC
Created attachment 147296 [details]
Partial Fix
The attached patch works only if the project uses no version control system.
If some versioning is used by the project, moving is handled by a VCSInterceptor, which would need to be updated as well to set the last-modified time correctly.
I've noticed that FileSystemInterceptor in git module contains this method:
copyDirFiles(File sourceDir, File targetDir, boolean preserveTimestamp)
This method is called from method doCopy with parameter preserveTimestamp = false.
I guess there can be a good reason for this (probably performance).
Ondra, is calling this method with preserveTimestamp = true risky?
Can versioning modules be safely updated to preserve timestamps when copying files?
Thank you.
> I rely heavily on date/timestamps and this side effect of the move was unexpected and
> took me several hours and I only manager to get most of it back the to the way it was
> before the move.
It seems quite risky to me. Various tools (other than NetBeans) can update last-modified time unexpectedly. I would recommend using some VCS whenever it is applicable. It can track history of changes and offers many other benefits.
Not sure this is P1, as only meta-data were lost. And last-modified time can be considered as quite a fragile piece of meta-data.
Thank you for reporting.
> The attached patch works only if the project uses no version control system. > If some versioning is used by the project, moving is handled by a VCSInterceptor, which would need to be updated as well to set the last-modified time correctly. > I've noticed that FileSystemInterceptor in git module contains this method: > copyDirFiles(File sourceDir, File targetDir, boolean preserveTimestamp) > This method is called from method doCopy with parameter preserveTimestamp = false. > I guess there can be a good reason for this (probably performance). > Ondra, is calling this method with preserveTimestamp = true risky? > Can versioning modules be safely updated to preserve timestamps when copying files? It makes sense to keep timestamp for moves/renames, but for copies? Are you sure it's the right way? I am not so convinced. Much more straightforward would be to call move instead of copy+delete. But i guess all versioning modules could be forced to keep the timestamp for copies if necessary. > Not sure this is P1, as only meta-data were lost. And last-modified time can be considered as quite a fragile piece of meta-data. sounds like a P4 to me, especially in case of renaming a project via UI. If the reporter is interested in keeping all timestamp i suggest renaminhg/moving in the favorites view. http://hg.netbeans.org/core-main/rev/eb47861d08e2 Fixed. Thank you. Integrated into 'main-silver', will be available in build *201407190718* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main-silver/rev/eb47861d08e2 User: Jaroslav Havlin <jhavlin@netbeans.org> Log: #244286: Moving a project does not preserve file and folder timestamps The copy operation is used internally during move. To recognize that the copy is called from a move (without API changes), new thread local variable was introduced. If this variable is set to true, the last-modified date of the target file is set after copying. Using NIO2, which could make the implementation simpler, should be considered for the next release. |