F5F Stay Refreshed Software Operating Systems Project files vanished, one day's effort disappeared

Project files vanished, one day's effort disappeared

Project files vanished, one day's effort disappeared

Pages (2): 1 2 Next
_
_Rex_Stone_
Junior Member
26
09-10-2016, 10:58 AM
#1
Could this be the result of a malicious OS? Others have reported random file deletions. It’s confusing why the folder appears empty even though it’s automatically created and files are added when you set it up. I tried running Recuva but couldn’t locate anything. You’re using Enterprise 1809 LTSC, right?
_
_Rex_Stone_
09-10-2016, 10:58 AM #1

Could this be the result of a malicious OS? Others have reported random file deletions. It’s confusing why the folder appears empty even though it’s automatically created and files are added when you set it up. I tried running Recuva but couldn’t locate anything. You’re using Enterprise 1809 LTSC, right?

C
CombatKids
Junior Member
4
09-10-2016, 11:38 AM
#2
The 1809 release included the removal of certain files... that's why it's feasible.
C
CombatKids
09-10-2016, 11:38 AM #2

The 1809 release included the removal of certain files... that's why it's feasible.

M
MarcoSheep
Junior Member
17
09-10-2016, 11:47 AM
#3
When a folder appears automatically, check the support community or official resources for guidance. Windows shouldn't remove files on its own; this usually occurs after upgrading to version 1809 and affects specific subfolders like "Documents" or "My Music." Post-upgrade, no reports indicated missing files, suggesting a possible hardware issue or software bug.
M
MarcoSheep
09-10-2016, 11:47 AM #3

When a folder appears automatically, check the support community or official resources for guidance. Windows shouldn't remove files on its own; this usually occurs after upgrading to version 1809 and affects specific subfolders like "Documents" or "My Music." Post-upgrade, no reports indicated missing files, suggesting a possible hardware issue or software bug.

S
sst04
Member
208
09-10-2016, 03:50 PM
#4
Windows doesn't remove files instantly. The information you saw was about particular settings during an upgrade. Microsoft provided free expert data recovery services for those impacted. Files disappearing can result from a bad drive, user mistake, or a program that accidentally or deliberately deleted them due to a bug.
S
sst04
09-10-2016, 03:50 PM #4

Windows doesn't remove files instantly. The information you saw was about particular settings during an upgrade. Microsoft provided free expert data recovery services for those impacted. Files disappearing can result from a bad drive, user mistake, or a program that accidentally or deliberately deleted them due to a bug.

R
Robymex95
Junior Member
20
09-11-2016, 02:42 PM
#5
Hello MS-DOS, I’m curious about the details. Which directory was involved? What programs were active? How did you store the file? Were cloud-based tools in use for updates? Did you rely on network SMB for saving? Was SharePoint Web App part of your workflow?
Regards, Elsa Ballerina
R
Robymex95
09-11-2016, 02:42 PM #5

Hello MS-DOS, I’m curious about the details. Which directory was involved? What programs were active? How did you store the file? Were cloud-based tools in use for updates? Did you rely on network SMB for saving? Was SharePoint Web App part of your workflow?
Regards, Elsa Ballerina

R
RoiBastian
Junior Member
7
09-13-2016, 12:47 PM
#6
It was a animation tool, the route remains consistent as I'm storing files in C:\program\projects\project directory. The remaining folders are being saved correctly. I didn't handle anything else.
R
RoiBastian
09-13-2016, 12:47 PM #6

It was a animation tool, the route remains consistent as I'm storing files in C:\program\projects\project directory. The remaining folders are being saved correctly. I didn't handle anything else.

T
Thumps209LV
Member
226
09-13-2016, 01:08 PM
#7
wtf really
T
Thumps209LV
09-13-2016, 01:08 PM #7

wtf really

C
Cyanstrophic
Senior Member
668
09-21-2016, 11:41 AM
#8
Certainly, the problem was observed only under particular conditions.
C
Cyanstrophic
09-21-2016, 11:41 AM #8

Certainly, the problem was observed only under particular conditions.

K
Kaldeo
Member
226
09-22-2016, 02:08 AM
#9
What's I'll say won't help you, and nothing blocks you, and you have workaround, and that is assuming you care, but I'll just say it as: best practices. It is best to not save anything personal in C:\. C:\ Requires elevated privileges to write to. I don't know if this applies to your case or not, but I have seen programs where when you save, despite failing due to lack of credentials, doesn't complain, and the user only gets the surprise when they reload their project. Now, yes you can set permissions of the sub folder in C:\ to rectify this problem, but you have no guarantee that it won't change, as this is a system level location. Other benefits in having it to your home directory: Project files are not visible by default by Windows search. Allowing you run your project from a search from the Start Menu Multi-user protection Avoids backups conflicts Ability to use Windows Ransomware protection system This is the best practice for any OS you use. Always use the home/personal directory to store your stuff. The only reason why C:\ root was ever used for personal data is because of MS-DOS, which had a char limits on path, and had no concept of accounts. Also, programs should be installed under Program Files. If you are using a legacy program, regardless, install it in Program Files (x86) (if 32-bit), and change the permission for that programs if it needs to write to itself (that is bad practice by developers, luckily, since Vista, with Microsoft clamping down on bad practices and security issues, and blocked this, and yes it made a lot of inconveniences to users, but devs fixed their shit). Program data should be saved on their appropriate locations in the OS, and not dumb them where they are installed. This also allow multiple users on the same system have their own config. Here is what I do (I am a developer): - My project is stored: C:\Users\GoodBytes\Projects\ - I tell the PowerShell to open to that folder by default, to speed things ups. - As I use WSL, I also tell the Linux distro to start there. - I set aliases in PowerShell and Linux to quickly jump to directory. For example, typing home in the command prompt or my Linux distro under WSL: "home" (without quotes), will jump me to C:\Users\GoodBytes. "doc" will jump me to C:\Users\GoodBytes\Documents, and "prj" to Projects. In your case, you can pin your project directory in the left side column in File Explorer (under: Quick access), to quickly jump to the location.
K
Kaldeo
09-22-2016, 02:08 AM #9

What's I'll say won't help you, and nothing blocks you, and you have workaround, and that is assuming you care, but I'll just say it as: best practices. It is best to not save anything personal in C:\. C:\ Requires elevated privileges to write to. I don't know if this applies to your case or not, but I have seen programs where when you save, despite failing due to lack of credentials, doesn't complain, and the user only gets the surprise when they reload their project. Now, yes you can set permissions of the sub folder in C:\ to rectify this problem, but you have no guarantee that it won't change, as this is a system level location. Other benefits in having it to your home directory: Project files are not visible by default by Windows search. Allowing you run your project from a search from the Start Menu Multi-user protection Avoids backups conflicts Ability to use Windows Ransomware protection system This is the best practice for any OS you use. Always use the home/personal directory to store your stuff. The only reason why C:\ root was ever used for personal data is because of MS-DOS, which had a char limits on path, and had no concept of accounts. Also, programs should be installed under Program Files. If you are using a legacy program, regardless, install it in Program Files (x86) (if 32-bit), and change the permission for that programs if it needs to write to itself (that is bad practice by developers, luckily, since Vista, with Microsoft clamping down on bad practices and security issues, and blocked this, and yes it made a lot of inconveniences to users, but devs fixed their shit). Program data should be saved on their appropriate locations in the OS, and not dumb them where they are installed. This also allow multiple users on the same system have their own config. Here is what I do (I am a developer): - My project is stored: C:\Users\GoodBytes\Projects\ - I tell the PowerShell to open to that folder by default, to speed things ups. - As I use WSL, I also tell the Linux distro to start there. - I set aliases in PowerShell and Linux to quickly jump to directory. For example, typing home in the command prompt or my Linux distro under WSL: "home" (without quotes), will jump me to C:\Users\GoodBytes. "doc" will jump me to C:\Users\GoodBytes\Documents, and "prj" to Projects. In your case, you can pin your project directory in the left side column in File Explorer (under: Quick access), to quickly jump to the location.

M
Maliwan99
Senior Member
346
09-24-2016, 12:30 AM
#10
It's a distinct partition from the OS installation. The C:\ drive is a 970 Evo Plus where the OS resides, while D:\ holds my software. You referred to C: because it was easier, but the rule remains valid even if the drive differs from the OS location.
M
Maliwan99
09-24-2016, 12:30 AM #10

It's a distinct partition from the OS installation. The C:\ drive is a 970 Evo Plus where the OS resides, while D:\ holds my software. You referred to C: because it was easier, but the rule remains valid even if the drive differs from the OS location.

Pages (2): 1 2 Next